Designing a truly cross‑device experience means treating the person as the unit of personalization—not the browser, device, or session. A common example is the onboarding modal or welcome popup: users are willing to see it once but seeing it multiple times across devices quickly becomes friction. This article explores this use case.

The use case

When a user logs in to Device A, the onboarding modal should show once; when the same user logs in on Device B, it should not appear again. In our current approach, we use Real-Time CDP (RTCDP) to manage this behavior across devices.RTCDP is the source of truth for the cross‑device “has seen modal” / frequency‑capping state. We define the rule at the person level (for example, “show the onboarding modal once per user across all devices”), and RTCDP evaluates it using its unified customer profile and identity graph. The resulting attribute or audience (for example, has_seen_onboarding_modal = true) is exposed to Adobe Target via the Adobe Experience Platform Edge Network. Target reads these RTCDP segments and profile attributes on each request, so suppression is near real time for edge—typically from a few seconds up to a couple of minutes. The exact latency depends on whether the audience is built using edge segments (evaluated on the edge with very low latency) or streaming segment or a combination of both, as well as on identity stitching. This ensures the modal is consistently suppressed once it has been seen on any device.

RTCDP‑centric cross‑device frequency capping with Target: Identity graph, Edge projection, and thirdPartyId coexistence

After introducing RTCDP‑based frequency capping, cross‑device identity is primarily managed in RTCDP, while Target can still use thirdPartyId (or other identifiers) to support experience delivery. RTCDP’s identity graph stitches together identifiers like ECID, CRM ID, login ID, and device ID into a unified profile, governed by merge policies (for example, authenticated over anonymous), and projects this to Edge profiles for same‑page / next‑hit personalization. On login, the application sends an identityMap with the login or customer ID as primary; RTCDP links Device A and Device B via that login/CRM ID and, once stitching and Edge projection complete (typically seconds to a few minutes), the “has seen modal” / popupViewed flag is computed once per person, not per device. When Target reads from RTCDP via the Adobe Target destination, it sees the same profile state on both devices.

In this model, RTCDP is the source of truth for person‑level frequency capping, and Target thirdPartyId can still be used where needed for cross‑device experience consistency and activation. It is not a requirement to remove thirdPartyId from Target for RTCDP‑based frequency capping to work; any issues observed with thirdPartyId and reporting are likely implementation‑specific, not a general constraint.

Implementing the modal using Web SDK

• Track the modal view: Use AEP Web SDK to send an XDM event with a field such as _atag.viewName = "popupViewed" (_atag is my company tenantID) representing the welcome modal), including the relevant identityMap (login identity), into an ExperienceEvent dataset that is enabled for profile.

• Define the audience in RTCDP: Configure a streaming segment (and corresponding edge segment) using a simple condition such as _atag.viewName = "popupViewed" (_atag is my tenantID). Mark the segment as streaming and ensure its merge policy is Edge‑enabled so it can be projected to Edge Profile and used in Target via the Target destination. This is sufficient for real‑time behavior: RTCDP evaluates streaming segments in near real time and projects them to the Edge. If you need more nuance—such as tracking the last time the popup was seen or enforcing frequency windows—use a computed attribute that captures those details.

• Activate to Target: Configure the Adobe Target destination with a DataStream that has Target and Experience Platform services, Edge Segmentation, and Personalization Destinations enabled; share the “‘popupViewed’” segment (or a popupViewed attribute).

• Use in Target: In Target, select the Adobe Experience Platform audience that represents ‘‘popupViewed’’ and combine it with other audiences using OR/AND as needed.

  On first login on Device A, the user doesn’t qualify yet, so Target shows the modal and RTCDP updates the profile. On Device B, the unified profile already has ‘popupViewed’ so the modal is automatically suppressed. Identity and frequency are handled upstream in RTCDP + Web SDK and Target focused purely on delivery.

RTCDP as the brain, Target as the delivery engine

Profile scripts in Target are handy but limited: they live only in Target’s own profile store, are hard to reuse in other channels, can add latency at scale, and depend heavily on whatever IDs you pass directly into Target. The broader platform strategy is to shift this kind of logic to AEP/RTCDP as the single source of truth.

In practice, that means no longer computing “has seen modal” inside Target but instead defining it as a segment or attribute in RTCDP, then letting Target simply read that state at decision time. Events like logins and modal impressions are collected via AEP Web SDK / Edge, RTCDP turns them into a streaming segment or computed attribute answering, “Has this profile ever seen the modal?”, and that state is shared to Target through the RTCDP Target destination so it’s available in real time. RTCDP also becomes the place where identity is solved: it stitches ECID, login IDs, CRM IDs, and device IDs into a single profile, applies merge policies, and projects Edge profiles for same‑page or next‑hit personalization. When the user logs in, you send an identityMap along with their login ID as primary; RTCDP connects Device A and Device B under one person, computes “has seen modal” once per person, and Target simply sees the same flag on both devices.

What you gain by moving to RTCDP

By using RTCDP to power the “has seen modal” frequency‑capping logic (in addition to what you can do in Target), you unlock several additional advantages:

• Person‑level state across channels: RTCDP computes the “has seen modal” / frequency cap at the person level and shares it with Target via Edge attributes/segments.

• Cross‑device by design: Cross‑device behavior comes from RTCDP’s identity graph and merge policies, rather than re‑implementing this logic per activity.

• Reusable business logic: The same RTCDP state can suppress Journey Optimizer messages, throttle Ad Cloud campaigns, and inform CJA/Analytics.

• Centralized governance: RTCDP is the single place to apply data‑use labels, consent, and activation rules.

• Co‑exists with Target identities: RTCDP Profile complements, not replaces, Target IDs (including thirdPartyId); they are designed to work together.

Target profile scripts still have valid use cases (for example, quick per‑session logic, Target‑only experiments, or when RTCDP isn’t available). For cross‑device, cross‑channel, identity‑dependent scenarios like this modal, RTCDP provides an additional, scalable option to centralize the person‑level “has seen modal” state and share it with Target, which then acts as the delivery engine. This RTCDP‑based approach is designed to co‑exist with standard Target identities such as thirdPartyId, especially when cross‑device personalization is involved, rather than replace them.