Is the only way to transmit events to the big data tables through an SDK?

You have several options for sending your events to the big data tables. One way is to integrate the SDK and event JS directly into your source code or utilise Google Tag Manager (GTM) to include them. Another approach involves using the SendEvent API method, which necessitates API integration.

Note: If you want to proceed with the Event API method, you can get the “Key” from the SDK and send it. Or, if you generate the “Key” yourself, you can send it directly.

Do I need to split my events table by table? Should I keep my event in different tables?

The choice between a single table or multiple tables should align with your overall data strategy and the needs of your customers who will be using these tables for event definitions and segment creation. Here are some considerations to help you decide:

1️⃣ If you anticipate a high volume of event data, split it into separate tables to improve query performance and data management.
2️⃣ If different types of events have significantly different attributes or fields, it may make sense to use separate tables. This can help maintain data integrity.
3️⃣ If you often need to retrieve data across multiple events or need complex joins between event data, a well-designed relational database with separate tables might be beneficial.
4️⃣ Consider the scalability of your solution. Splitting data into separate tables can make it easier to scale your system horizontally by adding more servers or resources to handle increased data volume.
5️⃣ Use separate tables to ensure that changes or issues with one type of event data do not impact others. This can be crucial for data quality and reliability.
6️⃣ If you want easy maintenance, Separate tables can simplify maintenance tasks like backups, indexing, and optimising for specific types of queries.
7️⃣ If your event data shares a similar structure and you want to maintain simplicity, you might consider keeping it in a single table. This can simplify your data model and reduce complexity.

Where will my events be written in the database?

In CDMP's database, events will be recorded in the "Big Data" tables. For standard e-commerce activities, page view events will be stored in the "page_view_events" table, while e-commerce-specific events like add to cart, remove from cart, view cart, and begin checkout will be logged in the "shopping_cart_events" table. Additionally, search events will be recorded in the "search_events" table, and add to wishlist events will be stored in the "wishlist_events" table.

For non-e-commerce applications, a custom events table can be created to accommodate custom event fields as per specific requirements.

It's important to note that the tables utilised for event storage must be designated as big data tables.

How can we collect different web site events into a single account?

To collect various website events into a single account in D·engage, you can follow these steps:

1️⃣ Determine the types of events and data you want to collect, such as page views or ecommerce events.
2️⃣ Utilize the Web SDK provided by D·engage to collect standard events like page views and ecommerce events.
3️⃣ For custom events, create a "Big Data" table in the D·engage admin panel. This table will store collected events, and you can define multiple tables based on specific needs.
4️⃣ Define the structure and content of the events in the custom table according to your business requirements. This offers flexibility in capturing any type of event.
5️⃣ Let user identification information using the Web SDK. If you have a user ID for logged-in users, you can use the following code snippet anywhere on your page:

dengage('setContactKey', 'user_unique_contact_key');

By following these steps, you can effectively collect various website events into a single account in D·engage and use the data to create behavioral segments.