Pseudonymous profile and Experience Event expirations

In this video, I’ll discuss the benefits of and the process for configuring time to live settings for experience events and pseudonymous profiles in experience Platform. These are the topics I’ll cover. I’ll start with a high level review of Experience Platform and the real time CDP next, I’ll review key points about profile service, the nature of pseudonymous and known customers, the process for configuring time to live for both experience events and pseudonymous profiles, and then how to assess the impact of these configurations. I’ll quickly review a high level diagram for experience platform and the real time customer data platform. A variety of data is ingested from your Adobe Own Solutions, like analytics, your data warehouse, an operational systems and potentially even partners and third parties. As this raw data enters the system, it’s sent to the data lake And if the data sets our profile enabled the profile store IDs from the profile store that customer profiles are distilled into actionable audiences to use in marketing workflows. The real time customer profile supports many types of engagement workflows per activation use cases. It’s used by the Real-Time CDP and Journey Optimizer, and it’s also the primary engine that power segmentation, audience management and activation to marketing and advertising channels. It’s not intended for long term data storage like data lakes and data warehouses. Profiles are based on various identifiers and have associated event data. For example, a person might visit your website, authenticate and then add a product to the car because that person logged in on your site. That web interaction and web identifier can be joined with your known or durable identifiers and other interactions and other channels like in-store purchases. There are other profiles that are based on less durable identifiers. These are referred to as pseudonymous profiles. They have the potential to merge with other profiles that use durable identifiers based on additional behavioral engagement. But the timeframe for this potential is relatively sure to keep your profiles within licensed entitlements. Time to live Configure ations can be applied to stale event data and pseudonymous profiles. This only applies to the profile store and doesn’t impact the data. Lake. This doesn’t apply to prospect profiles either, which automatically expire 25 days after ingestion into experienced platform. I’ll explain experience event time to live first. This configuration limits the number of days that behavioral event data lives within a dataset in the profile store. The only way you can configure this is through filing a support ticket. You’ll need to supply the data set name and the time to live and days again. This only applies to profile enabled data sets. The expiration value is added to all existing data in the data set and is evaluated for new ingestion based on the event, timestamp and data that exceeds the time to live date is removed. The timeline below illustrates profile richness that day 90 with and without experience event time to live configured to 60 days. You can verify the impact of configuring experience event time to live by reviewing the average profile richness report in the license usage dashboard. If you don’t see this report, it means you don’t have access and you’ll need to contact your administrator. Next, I’ll explain pseudonymous profile Time to Live. This configuration limits the volume of unknown or pseudonymous profiles in the profile store. It’s also handled through filing a support ticket. You must include the identity namespaces such as ECI, ID or Air ID, the Sandbox name, and the time to live in days. The identity namespaces I just mentioned represent those used in your digital channels that implement the experienced Cloud ID service or Adobe Analytics and come in to experience platform from data collection or the Connector. If you’re using a different analytics platform to measure your digital channels, then the identifier would be specific to the platform used last. This configuration is applied at the sandbox level, so it’s across the entire profile store for the sandbox specified. The timeline below illustrates what happens when pseudonymous time to live configured for 14 days for a returning visitor versus a one time visitor. Visitor A’s profile is extended because their first party cookie is extended during their second visit on day six and then again on the third visit on day 15. In contrast, visitor B’s profile is removed on the 15th day. Since another visit didn’t occur in the 14 day time period. You can also verify the impact of configuring PSEUDONYMOUS profile Time to Live by reviewing the addressable audience report in the license usage dashboard. If you don’t have access, contact your administrator. These are the main points I’d like to leave you with. After viewing this video Configuring Time to Live an Experience event as pseudonymous profiles is recommended to keep your profile store relevant and within the bounds of your licensed entitlements, both configurations require filing a support ticket and are not visible in experienced platform experience. Events and pseudonymous profiles. Remove through time to live implementation aren’t recoverable. You should notify your experienced platform users prior to implementing this configuration to avoid conflicts with segmentation lookback windows. Last, there are other data management and hygiene features available in Experience Platform that are beyond the scope of this video. I hope you found this video helpful. Good luck.