Audience filters

• • DMP event filters
  • DMP custom filters
  • Joining Traffic and DMP data
    • Joining via explodeUsers
    • Joining without explodeUsers

/dmp/traffic, /dmp/traffic/event and /dmp/traffic/custom support all existing traffic filters (see the note below) and provide two additional filters, dmp-event and dmp-custom.

DMP event filters

A DMP event filter allows you to specify a filtering predicate based on a standard property associated with the DMP event. For example, you may want to consider only the events with a specific origin or type. The available groups and the most popular items in each group can be listed using /dmp/traffic/event.

• The basic form of this filter is as follows:

  JSON

  {"type":"dmp-event", "group":"type", "item":"click"}
  

• Alternatively, it is possible to specify multiple items to match either of the values:

  JSON

  {"type":"dmp-event", "group":"origin", "items":["cxd-funnel", "cxd-cxensedisplay"]}
  

DMP custom filters

A DMP event filter allows you to specify a filtering predicate based on a custom property associated with the DMP event. The available groups and the most popular items in each group can be listed using /dmp/traffic/custom.

• The basic form of this filter is as follows:

  JSON

  {"type":"dmp-custom", "group":"campaign", "item":"Model S"}
  

• Alternatively, it is possible to specify multiple items to match either of the values:

  JSON

  {"type":"dmp-custom", "group":"advertiser", "items":["Tesla Motors", "Lexus"]}
  

• It is also possible to match any defined (non-null, non-empty) value:

  JSON

  {"type":"dmp-custom", "group":"newsletter"}
  

• Finally, a customer feature allows to match the items to be used in the filter with a pattern (see the linked wiki page for details such as supported groups) :

  JSON

  {"type":"dmp-custom", "group":"advertiser", "pattern":"Tesla*"}
  

Joining Traffic and DMP data

Traffic and DMP events are aggregated via two sets of APIs (e.g., /traffic/event and /dmp/traffic/event), which are associated with two sets of filters, (e.g., event and dmp-event). Both API sets however support filters from each other, both direct and via explodeUsers or the user having clause. In the following we explain practical implications of different ways of joining the data across the two API sets. Note that the join operation does not consider external user identities available to the caller

Assume the following traffic data:

Where each row corresponds to a traffic event and '...' corresponds to the columns containing event data. Now if we aggregate this data using /traffic with a traffic-based filter (assuming it matches the particular rows), we get 5 (traffic) events and 2 unique users.

Now assume the following DMP data:

Where each row corresponds to a DMP event and '...' corresponds to the columns containing DMP-event data. Now if we aggregate this data using /dmp with a dmp-based filter (assuming it matches the particular rows), we get 5 (DMP) events and 1 unique user.

Joining via explodeUsers

Now if we use /traffic with explodeUsers (or user having) wrapping a filter matching the DMP events given above, the result will be 3 events and 1 unique users. This is because first it will find the users that match the DMP filter (user0) using the DMP data, and then find all traffic events for these users in the traffic data. A practical application of such query is for example to explore user data beyond the events matching the exact DMP filter (for example a conversion).

There are two consequences of this behaviour:

1. The query will match disregarding the prnd values used in the events.

2. Explode modes, allEvents and consecutiveEvents, will both match all events for a given user.

Joining without explodeUsers

On the contrary, if we use /traffic with a filter matching the DMP events given above but without explodeUsers (or user having) , the result will be 2 events and 1 unique users. This is because first it will find the <user, prnd> pairs that match the DMP filter (<user0, 6> and <user0, 7>) using the DMP data, and then find all traffic events for these pairs in the traffic data (<user, rnd>). A practical application of such query is for example to explore user data limited only to the events matching the exact DMP filter.

Consequently, if we user /dmp with explodeUsers on a filter matching the traffic events given above, the result will be 5 events and 1 unique users. Without explodeUsers the result will be 4 events and 1 unique users, since in this example the last DMP event doesn't have a matching traffic event (which will not occur when the customer feeds a valid prnd value for each DMP event, but still is a possible scenario).

Last updated: June 23, 2026