Events

Events are basic activities performed by or towards a contact or company.

It is identified by a timestamp and/or a contact/company (dd_contact_id/dd_company_id).

Some events are anonymous, meaning neither the contact or the company performing the event is known (both dd_contact_id and dd_company_id will be NULL). For other events, we know only about the company, but not the contact (only dd_contact_id will be NULL).

For contacts associated with multiple companies, events are repeated to each company (dd_company_id) associated with the contact (dd_contact_id). This makes the schema ideal to answer account based questions.

To remove the repeated events by only including the event associated with the primary company of the contact, see dd_is_primary_event.

Row IDs vs activity IDs

Because of company fan-out, a single real-world event can appear on multiple rows in the events table (one per associated company). Each row has its own warehouse primary key:

• dd_event_id — event row ID (unique per row; do not use for event counts)
• dd_session_id — session row ID (unique per row; do not use for session counts)

Analytics Hub instead uses activity IDs, which identify the real occurrence and are shared across fan-out rows:

• dd_event_activity_id — COUNT(DISTINCT dd_event_activity_id) for events
• dd_session_activity_id — COUNT(DISTINCT dd_session_activity_id) for sessions

Exposure rows (e.g. ad impressions) have null activity IDs. Count impressions with SUM(quantity) where dd_tracking_type = 'exposure', not by counting rows or activity IDs.

Events can be grouped into sessions — indicated by dd_session_id (row id) and dd_session_activity_id (counting id). A typical example is a web session containing multiple page view events.

Visitors: COUNT(DISTINCT CASE WHEN dd_tracking_type <> 'exposure' THEN dd_visitor_id END).