Free AD0-E602 Practice Test

The scenario requires identifying profiles that performed a specific series of actions in a defined order: a purchase event, followed by another purchase event exactly five days later, all within a 90-day lookback window. This is the explicit function of sequential segmentation. This method allows marketers to build audiences based on a journey or a sequence of events, specifying the order and the time elapsed between each step. The other options, while related to segmentation, do not address the core requirement of event order.

A. Frequency Segmentation: This method counts how many times an event occurs within a timeframe but does not consider the order or the specific timing between events.
B. Recency Segmentation: This method identifies profiles based on when their last action occurred but does not support building rules based on a sequence of multiple actions.

1. Adobe Experience Platform Documentation

Segmentation Service overview: In the "Segmentation types" section

it states

"Sequential segmentation is used to build an audience of users who have performed a series of events in a specific order." This directly aligns with the question's requirement to find users who purchased and then purchased again.

2. Adobe Experience Platform Documentation

Segment Builder guide: The section "Event-based containers" details how to build sequential rules. It explains the use of "Then" logic to connect event containers

allowing the user to specify the time between events

such as "within 5 days of" or "after 5 days of

" which is precisely what the practitioner in the scenario needs to accomplish.

The decrease in segment size is explained by a Data Lifecycle Time to Live (TTL) policy on the Experience Event dataset. When a TTL is set (e.g., 30 days), any Experience Events older than that period are automatically deleted from the Profile Store. Since the segment was built using this event data, profiles whose qualification depended solely on events that occurred more than 30 days prior would no longer meet the segment criteria. As these old events expired between January 1st and the end of February, the corresponding profiles were removed from the segment, causing its total size to decrease.

B. More profiles met the segment criteria during the time difference. This is incorrect because if more profiles met the criteria, the segment size would have increased, not decreased from 25,000 to 10,000.
C. The created segment was activated to a destination. This is incorrect because activating a segment to a destination is an outbound process that sends audience data to an external system. It does not alter the segment's definition or size within Adobe Experience Platform. ---

1. Adobe Experience Platform Documentation, "Data Lifecycle overview." This document explains the function of Time to Live (TTL). It states, "When the TTL is reached, the data is deleted from the data lake, Identity Service, and Real-Time Customer Profile." This confirms that expired data is removed from the profile, which would directly impact segment evaluation.

2. Adobe Experience Platform Documentation, "Real-Time Customer Profile overview." This guide details how Profile is a centralized and unified view of the customer. It clarifies that Profile data is composed of data from various datasets. The removal of data from a source dataset (due to TTL) will be reflected in the unified profile, thus affecting segment membership.

3. Adobe Experience Platform Documentation, "Segmentation Service overview." This document describes how segments are dynamically evaluated. "As new data is ingested into Platform, all segments are evaluated and updated automatically." This implies that when data is removed (via TTL), segments are also re-evaluated, and profiles that no longer qualify are removed.

In Adobe Real-Time CDP, when creating a destination, the "Governance" step requires the user to specify the marketing intent for the data export. This is done by selecting one or more "marketing actions" (e.g., "Email Targeting," "Social Targeting"). If the available, predefined marketing actions do not align with the specific business purpose of the new destination, the user cannot complete this mandatory step. The solution is to create a new, custom marketing action within the Data Governance framework that accurately describes the intended use of the data.

A. Move to the activation flow: The activation flow is for sending audiences to an existing destination. The problem occurs during the creation of the destination itself, which must be completed first.
B. Select an audience: Selecting an audience is a step in the activation workflow, not the destination creation workflow. A destination must be fully configured before any audiences can be activated to it.

1. Adobe Experience Platform Documentation

Data Governance

Marketing actions: "Marketing actions

also known as marketing use cases

are actions that an Adobe Experience Platform data consumer can take

for which your organization wants to restrict data usage... If none of the core marketing actions provided by Adobe cover your use case

you can define your own." (See the "Create a marketing action" section in the Data usage policies user guide).

2. Adobe Experience Platform Documentation

Destinations

Create a new destination connection: The documentation outlines the destination creation workflow. The "Governance" step is described as follows: "Select the marketing actions that apply for this destination. You can select from Adobe-defined marketing actions or from marketing actions you created." This confirms that selecting a marketing action is a required step and that custom actions are a valid option.

In Adobe Experience Platform, an identity namespace provides context for identity data, indicating the type of identifier (e.g., email, phone number, ECID). These namespaces are fundamental to the Identity Service, which creates and manages identity graphs to form a complete customer profile. "Email" is a standard, out-of-the-box namespace provided by Adobe specifically for this purpose, allowing the system to recognize and link profiles based on a person's email address across different data sources.

A. Device name: This is a descriptive attribute of a device (e.g., "My iPhone"), not a unique, cross-system identifier used for identity resolution like a device ID (IDFA/GAID).
C. Segment: A segment is an audience or a collection of profiles defined by shared characteristics or behaviors; it is an output of profile data, not an input identity type.
D. Display Name: This is a user-friendly label used in the user interface for schemas, fields, or other components. It is metadata for system objects, not a customer identifier.

1. Adobe Experience Platform Documentation

Identity Service overview: "An identity namespace is a component of Identity Service that serves as an indicator of the context to which an identity relates. For example

a value of '[email protected]' is meaningless without a namespace to identify it as an 'Email' address." (See the section "Identity namespace").

2. Adobe Experience Platform Documentation

Standard namespaces: The official documentation provides a table listing the standard namespaces available in Identity Service. "Email" is explicitly listed as a standard

cross-device ID with the Identity Symbol "Email". (See the table in the "Standard namespaces" section).

3. Adobe Experience Platform Documentation

Identity Service UI overview: Screenshots and descriptions of the Identity Service UI show "Email" listed as a standard namespace

reinforcing its role as a primary identifier type within the platform. (See the section "View identity namespaces").

The question describes a "batch segment," which by default is evaluated on a scheduled basis, typically once every 24 hours. To obtain an updated count for the analytics team before the scheduled run, the practitioner must manually initiate an on-demand evaluation. This process is executed as a "segment job." Running a segment job re-evaluates the segment's logic against the most current profile data in the data lake, thereby updating the segment's membership and providing the accurate, up-to-date count needed for the campaign launch.

A. Re-create the segment: This is incorrect. The segment's definition is sound; re-creating it is an inefficient and unnecessary step that does not trigger the required data refresh.
B. Streaming segment: This is incorrect. The scenario explicitly states the use of a "batch segment." Streaming segmentation is a different method for real-time qualification and is not the tool being used.

1. Adobe Experience Platform Documentation, "Segmentation Service overview". In the "Batch segmentation" section, it states, "Batch segmentation is the process of periodically evaluating segment definitions and qualifying audiences for segments. By default, batch segmentation jobs run every 24 hours." This establishes the nature of batch segments and their scheduled evaluation.

2. Adobe Experience Platform Documentation, "Evaluate a segment". The section "On-demand evaluation" explicitly states, "You can evaluate batch segments on-demand. This will run a segment job to produce an audience segment." This directly confirms that running a "segment job" is the correct on-demand action.

The primary value demonstrated in the scenario is the shift from a slow, 7-day batch process to a near real-time data stream for audience activation. This change directly impacts two key areas: speed and campaign effectiveness.
1. Time-to-market (B) is a direct measure of the operational improvement. The time required to activate a segment of "likely-to-churn" customers in Facebook has been reduced from up to 7 days to near real-time. This acceleration is a core value proposition of Real-Time CDP.
2. Cost Per Action/Acquisition (CPA) (C) measures the campaign's financial efficiency and effectiveness. By targeting customers with more timely and relevant data, the retention campaign is more likely to succeed, leading to a higher conversion rate (i.e., more customers retained). This improved performance results in a lower cost for each successful retention action, directly reflecting the value of the new system.

A. CPM: Cost Per Mille (CPM) measures the cost of ad impressions, not the effectiveness of the campaign in driving a specific business outcome like customer retention.
D. AOV: Average Order Value (AOV) is irrelevant in this context, as the campaign's goal is to prevent customer churn, not to increase the value of a sales transaction.

1. Adobe Experience League, Real-Time Customer Data Platform Documentation. The overview emphasizes activating profiles "throughout the customer journey." The value in this scenario comes from acting on a churn signal at the right moment, which was previously delayed. This speed is captured by "Time-to-market." (Source: Adobe Experience League, "Real-Time Customer Data Platform Overview," Section: "What is Real-Time Customer Data Platform?").

2. Adobe Business Whitepaper, "Reimagine the Customer Journey with a New Breed of CDP." This document discusses how a Real-Time CDP enables businesses to "deliver the next best experience in the moment" and "improve marketing ROI." A lower CPA is a primary indicator of improved marketing ROI and campaign performance, which is achieved by acting on timely data. (Source: Adobe, "Reimagine the Customer Journey with a New Breed of CDP," Page 4, Section: "Improve marketing ROI").

3. Adobe Experience League, "Sources and Destinations." The documentation on streaming destinations like the Facebook Conversions API connector highlights the ability to "send audience and event data... in near real-time." This capability directly enables a reduction in "Time-to-market" for audience activation compared to batch file uploads. (Source: Adobe Experience League, "Destinations Overview," Section: "Streaming destinations").

The company policy restricts data sharing to datasets containing only indirectly identifiable data. Within the Adobe Experience Platform's Data Usage Labeling and Enforcement (DULE) framework, identity data is categorized with 'I' labels. The I1 label is for directly identifiable data (e.g., name, email), while the I2 label is for indirectly identifiable data (e.g., cookie ID, device ID). Based on the policy, only datasets with the I2 label can be activated to destinations. Therefore, Dataset #2 and Dataset #3, both labeled 'I2', are the only ones that comply with the sharing policy. Datasets #1 and #4 are labeled 'I1' and cannot be shared.

A. Dataset #1 is labeled I1 (directly identifiable), which violates the company policy for sharing.
B. Both Dataset #1 and Dataset #4 are labeled I1 (directly identifiable), violating the sharing policy.

1. Adobe Experience Platform Documentation

Data Governance

"Data usage labels": This official documentation defines the standard data usage labels.

Section: "Identity data labels": It explicitly defines I1 as "Data that can be used to directly identify or contact a specific person" and I2 as "Data that can be used to identify or contact a specific person only in combination with other data". This directly supports the logic that I2 corresponds to "indirectly identifiable data".

2. Adobe Experience Platform Documentation

Data Governance

"Data usage policies overview": This document explains how labels are used to create and enforce data governance policies.

Section: "Policy enforcement": It states

"When a user attempts to perform an action in Experience Platform that has a data usage policy defined for it... the policy is evaluated to see if it has been violated. If a policy violation would occur

the action is prevented." This confirms that activating a dataset with an I1 label would be blocked by a policy restricting directly identifiable data.

Batch ingestion in Adobe Real-Time CDP is the most suitable choice for a requirement of automatic authentication. This method utilizes source connectors that are configured once with the necessary authentication credentials (e.g., API keys, OAuth2 tokens, access keys). After this initial setup, the Adobe Experience Platform automatically authenticates with the source system on a recurring schedule to ingest data files without any further manual intervention. This "set it and forget it" model is the essence of automatic authentication from the platform's perspective.

B. Streaming: Streaming ingestion requires the client-side application to manage authentication, typically by obtaining an access token and including it in the header of every API request, which is less of a platform-managed automatic process.
C. Real-Time: "Real-Time" describes a capability of the platform or the result of streaming, but it is not a distinct ingestion method itself. The primary ingestion methods are Batch and Streaming.

1. Adobe Experience Platform Documentation

Sources Overview: This document explicitly categorizes data ingestion into two primary methods: batch and streaming. It states

"Batch ingestion allows you to ingest data in bulk by uploading files... Streaming ingestion allows you to send data to Platform from client and server-side devices in real time." This confirms that "Real-Time" is not a distinct ingestion type.

Source: Adobe Experience Platform Documentation

"Sources overview

" Section: "Batch ingestion" and "Streaming ingestion."

2. Adobe Experience Platform Documentation

Batch Ingestion Overview: This guide explains how batch ingestion works. "Batch ingestion allows you to ingest a large amount of data into Adobe Experience Platform at once... Data can be uploaded in file form (such as CSVs) or through a source connector." The use of source connectors with a one-time authentication setup is central to this method.

Source: Adobe Experience Platform Documentation

"Batch ingestion overview

" Section: "How does batch ingestion work?".

3. Adobe Experience Platform Documentation

Amazon S3 Source Connector: The documentation for a typical batch source connector like Amazon S3 details the one-time authentication process. "To connect S3 to Platform

you must provide a value for your access key and secret key." Once provided

the platform uses these credentials for all subsequent scheduled ingestions.

Source: Adobe Experience Platform Documentation

"Create an Amazon S3 source connection in the UI

" Section: "Connect to Amazon S3."

4. Adobe Experience Platform Documentation

Streaming Ingestion Overview: This document outlines the authentication requirements for streaming

which differ from the batch connector model. It states

"All calls to Platform APIs must be authenticated... your request must include your access token in the Authorization header." This highlights the per-request authentication responsibility of the client application.

Source: Adobe Experience Platform Documentation

"Streaming ingestion overview

" Section: "Authentication and authorization."

Adobe Privacy Service enables organizations to manage customer data privacy requests (e.g., access or delete under GDPR/CCPA) for Adobe Experience Cloud applications. This is accomplished through two primary mechanisms. First, the application must be explicitly integrated with the Privacy Service for the service to locate and act upon the relevant data. Second, Adobe provides self-serve tools—a dedicated user interface and an API—for customers to submit and track these privacy requests without needing direct intervention from Adobe support for each job.

A. On-prem applications: Adobe Privacy Service is designed to work with Adobe's cloud-based Experience Cloud solutions, not customer-hosted on-premise applications.
C. Real-time applications: While some integrated applications operate in real-time (e.g., Adobe Target), this is a functional characteristic, not a category for Privacy Service integration. Both real-time and non-real-time applications can be integrated.

1. Adobe Experience Platform Privacy Service Documentation

Overview: "Privacy Service provides a RESTful API and a user interface to help you manage these requests... for data stored in Adobe Experience Cloud applications." This supports the "self-serve" nature (UI/API) of the service.

Source: Adobe Experience League. Privacy Service overview. Retrieved from https://experienceleague.adobe.com/docs/experience-platform/privacy/home.html (Refer to the introduction section).

2. Adobe Experience Platform Privacy Service Documentation

Supported Applications: This section explicitly lists the Adobe applications that are integrated with and supported by the Privacy Service. This confirms that an application must be part of this integrated ecosystem to be subject to Privacy Service requests.

Source: Adobe Experience League. Supported Adobe applications. Retrieved from https://experienceleague.adobe.com/docs/experience-platform/privacy/applications/overview.html (Refer to the list of applications).

Adobe Experience Platform (AEP), the foundation of Real-Time CDP, provides an event-based alerting system. To receive notifications for data ingestion errors from a source connection, a user must subscribe to alerts for the specific dataflow. The system offers predefined alert types, including Source flow run failed. By subscribing to this alert for a particular source dataflow, the practitioner will receive a notification—either in the UI or via email—whenever that specific data ingestion process encounters a critical error and fails to complete successfully. This is the direct and intended method for this use case.

B. Subscribe to failure alerts from monitoring Ul: This is imprecise. While you can access dataflow monitoring from the UI, the subscription action is tied specifically to a dataflow's properties, not a generic subscription "from the monitoring UI."
C. Create failure alerts in source workflow: This is incorrect terminology. Users do not "create" alerts within the source dataflow (referred to as a workflow here). Instead, they "subscribe" to existing, system-defined alert types.

1. Adobe Experience Platform Documentation

Sources > UI guides > Subscribe to sources alerts in the UI.

Section: "Subscribe to alerts"

Content: This document explicitly states

"This document provides steps on how to subscribe to email alerts for your source dataflows in the UI." It then lists the available alert types

which include Source flow run failed

directly supporting the terminology and action described in the correct answer.

2. Adobe Experience Platform Documentation

Sources > UI guides > Monitoring dataflows for sources in the UI.

Section: "Dataflow runs"

Content: This guide explains how to view the status of dataflow runs

including "Failed" statuses. It shows that the monitoring dashboard is for observing outcomes

while the alert subscription (described in the first reference) is the mechanism for proactive notification of those outcomes.

3. Adobe Experience Platform Documentation

Platform services > Alerts > Alerts overview.

Section: "Introduction"

Content: This document provides a high-level overview of the alerting framework

confirming that users can "subscribe to alerts for specific events

such as when a dataflow run has failed during data ingestion." This validates that subscribing to failure events for dataflows is the correct platform feature to use.