Understanding the Data Expiration Policies
To ensure that the data you collect and deliver represents recent activity by actual users, the Oracle Data Cloud platform has rules and standards that govern when your data expires. Oracle determines when data expires using a number of factors, including ID type, metadata attributes, and online traffic behavior. As a result, DMP retains and provides only data that meets strict recency standards.
Bot Detection: To ensure data quality, the Oracle Data Cloud platform uses several different techniques to identify bot traffic and remove related profiles. For example, the platform removes profiles for which more than 4,000 categories have been set within any 24-hour period.
Understanding Oracle Data Cloud platform data expiration policies helps you to explain why your audience contains the number of profiles it does and why that number may differ from your own estimates. For example, suppose you are a publisher of a sports news website. You know how many people visit your pages based on your site analytics data and therefore can estimate the amount of inventory in your categories. When you log into the Oracle Data Cloud platform and create an audience, the estimated reach of that audience is similar to but somewhat smaller than your own estimate.
Much of the variation in the audience numbers is caused by the expiration of profiles and other data. For example, if 10,000 users visit your site, and 500 never come back, the number of profiles drops to 9,500 almost immediately. Similarly, if 1,000 users revisit your site within a day but don't return after that, their profiles expire in a week. So a net total of 8,500 profiles results from the 10,000 original site visits. That number changes over time depending on how many users revisit your site regularly.
Additionally, when you deliver your audience to a media execution platform, the actual number of profiles delivered is less than then the audience reach. This is because the overlap between the Oracle Data Cloud platform and the media execution platform is never 100%.
Profile Expiration
User profiles expire when they no longer represent recent data. When a profile expires, the DMP platform deletes it from the profile store. As a result, it can't be assigned to categories or included in audiences, and therefore can't be delivered as user data. For example, if a larger than usual number of users visit your sports site during World Cup but do not visit regularly after that, their profiles all expire around the same time. As a result, there could be a noticeable drop in audience reach in a short period.
Oracle uses two factors determine when a profile expires:
- Recency. The time that the profile was last seen on the Oracle Data Cloud platform network.
- ID Source. The nature of the ID by which a profile is identified in the Oracle Data Cloud platform network. (See ID Management for more information about how the Oracle Data Cloud platform handles IDs.)
Oracle calculates profile expiration by adding the time-to-live (TTL) of its ID type to the time when it was last seen on the network. Different ID sources can have different TTL policies, but currently both Oracle Data Cloud cookies and MAIDs (including IDFA and Google AdID) share a maximum TTL of 30 days.
For example, if a user with an AdID visits your website on December 14 and 15 but does not return, their profile expires 30 days later on January 15.
The expiration date of a profile is extended on each visit, so it can stay active indefinitely. There is no maximum lifespan. Because most users visit the same sites frequently, their profiles are unlikely to expire based on their last-seen date and TTL. Profiles are more likely to expire because users delete their cookies.
New Profile Expiration
To ensure that only active, valid profiles are stored in the Oracle Data Cloud platform, shorter expiration dates apply when profiles are less than 24 hours old. The expiration date changes based on the age of the profile. Profile age is defined as last-seen time minus first-seen time. The following table summarizes the expiration rules for new profiles:
| Profile Age | Expiration |
|---|---|
| Less than 10 minutes | 1 day |
| Between 10 minutes and 1 hour | 2 days |
| Between 1 hour and 24 hours |
7 days |
| Older than 24 hours | 30 days |
In this example, a user linked to an Oracle Data Cloud cookie visits your website on days 0 and 20. The same user visits other sites in the network on days 0 and 40, but is not seen on the network after day 40.
Because this user's profile is based on an Oracle Data Cloud cookie, it has a TTL of 30 days. It will therefore expire on day 70 (40 + 30).
Category Expiration
Categories expire when profiles are no longer classified into them. For example, if you created a category for users who live in Arizona but no longer collect location data, that category expires because no profiles are being classified into it. Expired categories can't be used for targeting.
By default, categories expire 90 days after a profile was last tagged with it. The last-tagged profile must be alive for the category to be available for targeting. So if that profile expires before 90 days, the category can't be used for targeting even if it has not expired.
The default category TTL can be extended to a maximum of 180 days, but an exception requires approval from the Oracle Data Cloud taxonomy team. You may need an extension if you match or overlap IDs delivered from the Oracle Data Cloud platform with your own private IDs that have longer TTLs. There is significant cost, processing, and work associated with these extensions, however, so you should ask for one only if it is truly required.
You can request approval by contacting your Implementation Consultant during onboarding or by contacting your Customer Service Manager after implementation is complete.
Category Expiration Example
In this example, a user profile visits your site on days 0, 20, and 40. On days 0 and 40, classification rules in the Oracle Data Cloud platform classifies the profile into Category A. On day 20, the profile is classified into Category B. The user profile remains active and you are using the standard category TTL of 90 days.
In this scenario, Category A is available for targeting from day 0 to day 130. Category B is available from 20 to day 110.
Cookie Expiration
Oracle Data Cloud cookies expire, but their expiration is unlikely to affect the life span of profiles associated with them. Client-side browser cookies have a TTL of 180 days, which resets whenever the associated browser views a page that includes an Oracle Data Cloud tag. Profile TTLs also reset at each page view, but for a shorter time (30 days). So the cookie expiration date is always much farther in the future than the profile expiration date.
Cookie Expiration Example
In this example, a profile visits your web site on days 0, 30 and 70. On each visit, the cookie expiration date is reset to 180 days from the date of the visit. The current expiration date is therefore day 250 days (70 + 180).
Profile Expiration and Category Availability
Profile expiration can affect the availability of categories. This section includes two scenarios that illustrate this interaction.
Profile Expiration Scenario 1
A user visits your site on days 0 and 20 but does not return. They also do not visit any other sites in the Oracle Data Cloud platform network. On the first visit, the Oracle Data Cloud platform creates a profile and classifies it into category A. On the second visit, the profile is classified into category B. This profile is the last one assigned to each of the two categories.
Because the TTL for a cookie-based profile is 30 days, the profile expires on day 50. Based on their TTLs, the categories would not expire till days 90 and 110. But they are available for targeting only until day 50 because the profile expires then. Categories are available for targeting only as long as their last-assigned profile is still active.
Profile Expiration Scenario 2
If the user in the previous scenario regularly visits other sites in the network after visiting your site, the profile does not expire as before. Categories A and B s are therefore available for targeting for a full 90 days from the profile's last visit. Category A is available from day 0 to day 90. Category B is available from day 20 to day 110.
Deleted Cookies and MAIDs
Deleting the Oracle Data Cloud cookie or a MAID affects profile expiration and availability. The example in this section concerns a cookie deletion, but deleting a MAID has the same results.
User A visits your site on day 0 and receives an Oracle Data Cloud cookie and is added to the profile store. The user also visits your site on day 20 and visits other network sites on days 0, 20, and 40. On day 50, the user deletes their Oracle Data Cloud cookie. The same user returns to your site on day 60, thereby generating a new Oracle Data Cloud cookie and profile (Profile B).
Because its cookie was deleted, Profile A is not seen on the network after day 40. The Oracle Data Cloud platform doesn't receive notifications when cookies are deleted, so the profile expires based on its last-seen date and its TTL rather than on the day the cookie was deleted. In this case, the profile expires on day 70 (40 + 30).
When the user visits your site again on day 60, the Oracle Data Cloud platform generates a new Oracle Data Cloud cookie and profile (Profile B) with expiration based on a new set of last-seen dates.
When the platform sees a browser, it tries first to find a previous cookie ID to reuse. If an old cookie ID can be used, previous offline profile information is copied back to the cookie.
Cookie deletion also affects when and how profiles are available for targeting. For example, Profile A is available for targeting from day 0 to day 70, the days on which the profile was created and when it expired. But the type of availability varies during this period. While the Oracle Data Cloud cookie for Profile A exists, the profile can be included in audience deliveries that use either server data transfer (SDT) and pixel delivery methods. From day 50 (when the user deletes the cookie) to day 70, the profile can be delivered only by SDT. Pixel deliveries require the cookie to be seen on the client site so the pixel can fire in the container. Because the cookie has been deleted, the pixel can't fire.
If the user had deleted all cookies (not just the Oracle Data Cloud cookie) on day 50, SDT delivery would also be impossible. The cookies required to identify the user on the execution platforms would have been deleted, so the delivery could not occur.
About cookie-based profile creation
To ensure that profiles represent targetable users, DMP does not create a user profile the first time it receives a tag call from a web browser. Because many initial tag calls are the only contact with a browser, creating profiles in this case is wasted effort. (The initial tag call is captured for reporting in the DMPand is included in the Site Hits Report.)
Instead, the DMP waits for a second tag call to create the profile. To facilitate the eventual creation of the profile, however, the DMP drops two cookies on the browser after the first tag call:
- A regular Oracle Data Cloud cookie
- A temporary cookie that contains all the details needed to classify the data (site ID, phints, ID swap ID, and so on).
When the DMP receives a second tag call from the browser, it creates a profile and classifies the data based on the temporary cookie. It then deletes the temporary cookie, classifies the data from the second call, and applies the usual targeting logic.
The profile creation and TTL logic treats cookies that expire and are then seen again (intermittent cookies) as new. For example, suppose the DMP created a user profile for a browser some time ago, but that profile was later deleted because of inactivity. If the DMP receives a tag call for that device, the profile creation logic begins at the first step, as if the browser had never been seen. In other words, the browser would have to be seen again before a new profile was created. The cookie ID in the second profile is the same as in the first because it is based on the same cookie.