DMP Metrics
Last updated
Was this helpful?
Last updated
Was this helpful?
These are all the metrics available in the DMP product for analyzing the performance of your cookie pools and trackers. Additionally, when reviewing metrics, you can always use the to access our articles about a specific metric.
You can learn more about how metrics are handled by visiting the Metrics page.
This metric displays how many cookies have expired within the configured time frame. Cookies expire based on the TTL, which is the number of days after which a cookie will expire, configured when creating the cookie pool.
Example: You create a cookie pool with a TTL of seven days and install it on your homepage. The cookies generated by your users' access will be available for targeting for seven days. After this period, the cookies will expire. This means that in a retargeting campaign, for example, you will impact users who visited your website in the last seven days. In this graph, you can observe that on June 19th, just under 5 cookies expired, on June 20th no cookies expired, and on June 21st just under 5 cookies expired, and so on.
This metric shows the maximum amount of cookies allowed in the pool as configured.
Example: When creating or editing a cookie pool, you can set the maximum amount of cookies in the pool. This will limit the total number of cookies your pool can contain. In this graph, you can observe that a maximum size of 100,000 cookies was defined for this cookie pool.
This metric shows the actual size of the pool, meaning it will show how many cookies are or were in the pool within the configured time frame.
Example: On this graph, you can observe the size of a cookie pool in the defined time frame. This metric can be used to gather knowledge about how many cookies are generated within the configured time frame, which will allow you to set a maximum size for the pool that is in the same range as the number of users on your website.
This metric shows the number of cookie synchronizations, meaning it shows when a collected cookie has been synchronized with our platform and later with the exchanges as well, which allows you to target users more precisely.
Example: On this graph, you can observe the number of synchronizations that happened in a defined time frame. When a user accesses your website, a cookie will be requested for him, after receiving this cookie, it will be analyzed if this user already has a cookie or not, if he does the new cookie will be synchronized with the already existing one, updating its data on the platform, if he doesn't a cookie will be created for him on the platform.
This metric shows the median remaining time a cookie is still available in the pool until expiring in the determined time frame.
Example: When you create your cookie pool you can set the number of days in which a cookie will expire, this metric shows you how much time you have until a cookie expiration. On this graph, the time frame was 1 week, divided into daily periods, represented as dots, you can observe that on June 20th there was less than 1 day until some of the cookies in the pool expired.
This metric shows how many actions were executed by your tracker in the configured time frame, you can also group the provided data by tracker or by event according to your needs.
Example: On this graph, you can observe an increase in the number of actions at 6 AM. The graph displays a time frame of 3 hours divided into 5-minute intervals represented as data points. After creating a tracker, you will need to set up events and actions. Each time a tracked event occurs, the configured actions associated with that event will also be executed. For instance, an 'add to cart' event might trigger an action to track the added product in the catalog. This metric indicates when and how often the action is executed within that time frame.
This metric shows when an event has been tracked, but, the action linked to it has failed, you can also group the provided data by tracker or by event according to your needs.
Example: When a user adds a product to their cart on your website and this event is configured to be tracked, with an action to track it in the catalog, the event itself is tracked successfully. However, the action to update the catalog failed, resulting in the product not being tracked. In the graph, you can observe that the action failure rate is typically 0%. However, there are moments where the action failure rate peaks near 40%. The graph covers a time frame of 3 hours, divided into 5-minute intervals represented as data points.
This metric shows the amount of users' expirations that occurred in the defined time frame.
Example: When configuring a tracker, you can set a tracking period after which the user will expire. This metric shows the number of expirations that occurred. On this graph, you can observe that between 4 AM and 5 AM, nearly 50 tracked users expired.
This metric shows the configured maximum number of users to be added to the tracker.
Example: When creating or editing a tracker, you will set the maximum number of users allowed to be added to your tracker. This metric displays that data. In this graph, you can observe that the tracker was configured to accept up to 1 million users
Whenever a user performs a new tracked activity on your website, this will be tracked, this metric will show the number of new activities tracked in a defined time frame, you can also group the provided data by tracker or by event according to your needs.
Example: You have an 'add to cart' event configured on your tracker. Whenever a user adds a product to the cart, it counts as a new activity. On this graph, you will notice that the number of new activities increases after 6 AM. You will also observe that this graph covers a time frame of 3 hours, divided into 5-minute intervals represented as data points.
This metric shows the remaining time a user is still available in the tracker until expiring in the determined time frame.
Example: When you create your tracker you can set the number of days in which the tracked activity will expire, this metric shows you how much time you have until a user expiration. On this graph, the time frame was of 1 week, divided into daily periods, represented as dots, you can observe that on June 20th there was less than 1 day until some of the users in the tracker expired.
This metric will show how many users were in the tracker in the defined time frame.
Example: After setting up a tracker on your website, your website's users will begin to be tracked. The number of users tracked within a defined time frame is the data shown in this metric. On this graph, you will notice that the number of tracked users between 4 AM and 6 AM was nearly 400 thousand.
This metric displays the total number of identifiers added to the pool, in the defined time frame.
Example: As mobile users navigate through your website pages, or apps, in which you have installed a tracker configured to add users to an identifier pool, they will be added to the pool. On this graph, you can follow your identifier pool's growth as the users' identifiers are being added to it, the defined time frame was 1 week, divided into daily periods, you will notice that on Dec 31, a little more than 20 identifiers were added to the pool, and in the following days this number decreases to 3 per day, and then it increases again, to 5 identifiers added, on Jan 3.
This metric shows the number of identifiers enabled at least in one exchange, in the defined timeframe.
Example: As the identifiers are being added to your pool, the platform will send the identifiers to the selected ad exchanges and verify if the identifiers are enabled in their databases, this syncing process can be valuable for retargeting campaigns.
This metric displays the number of Identifiers in the pool that have expired in the defined time frame.
Example: You create an identifier pool with a TTL of seven days and install it on your app. The gathered identifiers will be available for targeting for seven days. After this period, the identifiers will expire. This means that in a retargeting campaign, for example, you will impact users who used your app in the last seven days. On this graph, the defined time frame was 1 week, divided into daily periods, you will notice that from Dec 30 until Jan 1, there was 1 expiration per day, then no expirations on Jan 2, and after that, it comes back for 1 expiration per day until Jan 5.
This metric shows the number of identifiers manually removed from the pool, in the defined time frame.
Example: When setting a tracker for an identifier pool you will be able to select between adding or removing identifiers from your pool, this metric displays the amount of identifiers that are being removed from the pool by this process.
This metric shows the maximum number of users the Identifier Pool was configured to accept, in the defined time frame.
Example: When creating or editing an identifier pool, you can set the maximum number of identifiers it can contain. This will limit the total number of identifiers your pool can contain. On this graph, the configured time frame was one week, divided into daily periods. You will notice that the maximum size configured for this pool did not change.
This metric shows the actual size of the pool, meaning it will show the number of identifiers that are or were in the pool within the configured time frame.
Example: On this graph, you can observe the size of an identifiers pool in the defined time frame. This metric can be used for gathering knowledge about how many identifiers are added to your pool within the configured time frame, which will allow you to set a maximum size for the pool that is in the same range as the number of users on your website. In this picture, you will notice that on December 30, there were 12 users in this pool, and in the following days this number decreased to 10 users, and on January 5, there were 8 users in the pool.
This metric shows the median remaining time an identifier is still available in the pool until expiring in the determined time frame.
Example: When creating your identifier pool you can set the number of days in which an identifier added to the pool will expire, this metric shows you the median time you have until an identifier expiration. On this graph, the defined time frame was 1 week, divided into daily periods, you will notice that on Dec 30 the median was around 16 days until the identifiers expire, and in the following days this median kept increasing until Jan 5, when it was around 23 days until the identifiers expire.
