• "Give me all customers who have an unpaid bill and haven't made a payment"
• It's like a SQL WHERE clause

Audience = The resulting group of people who match that rule

• The actual list of profiles: Alice, Bob, Carol, Frank, Grace, Iris
• This is what gets used in journeys and campaigns

In AEP, when you create a "segment definition," it automatically produces an "audience." Adobe has been migrating terminology from "Segments" to "Audiences" — so in the UI you'll mostly see Audiences.

2. Types of Audiences

a) Batch Audiences (Segment Builder)

• Evaluated periodically (once every 24 hours by default, or on-demand)
• Uses the Segment Builder UI with drag-and-drop rules
• Best for: campaigns, scheduled sends, large audiences
• Example: "All customers with unpaid bills" — evaluated daily

b) Streaming Audiences

• Evaluated in real-time as data flows in
• Profile qualifies/disqualifies the moment an event arrives
• Best for: time-sensitive triggers, journeys
• Example: "Customer just received a bill" — triggers instantly

c) Edge Audiences

• Evaluated on the edge network (CDN level)
• Ultra-low latency (milliseconds)
• Best for: same-page personalization, web/app experiences

For your capstone, you'll use Streaming for the journey trigger (react to events in real-time).

3. Segment Builder — How It Works

The Segment Builder UI has these components:

Key concepts in the builder:

• Attributes = Profile fields (firstName, accountStatus, churnRiskScore)
• Events = ExperienceEvents (bill_generated, payment_received)
• Include = Profiles that MUST match these conditions
• Exclude = Profiles that must NOT match these conditions
• Time window = "In last 30 days", "In last 7 days", "Any time"

4. Adobe Journey Optimizer (AJO)

AJO is the tool that orchestrates the customer experience — it decides who gets what message, when, and through which channel.

Core Components of AJO:

a) Journeys

A journey is a multi-step, automated workflow triggered by an event or audience qualification.

Trigger ──► Action ──► Wait ──► Condition ──► Action ──► End

Journey building blocks:

b) Channels (messaging)

AJO supports multiple channels:

• Email — rich HTML content
• SMS — text messages
• Push Notifications — mobile app alerts
• In-App Messages — messages inside your app
• Direct Mail — physical mail triggers
• Web — on-site personalization

c) Messages / Content

Each action uses a message template with:

• Subject line / body — static + dynamic content
• Personalization — using profile attributes like {{profile.firstName}}
• Content decisions — powered by Offer Decisioning

5. Journey Entry Types

Read Audience (Batch)

• Takes a pre-built audience and pushes all members through the journey
• Can be one-time or recurring (daily, weekly)
• Example: "Every day at 9am, push all unpaid-bill customers through the reminder flow"

Audience Qualification (Streaming)

• Triggers when a profile enters or exits an audience
• Real-time: as soon as profile qualifies, they enter the journey
• Example: "The moment a customer's bill is generated, start the payment reminder flow"

Unitary Event (Streaming)

• Triggers on a specific event for a profile
• Most real-time option
• Example: "When a bill_generated event arrives for CUST003, enter CUST003 into the journey"

For your capstone, you'll likely use Unitary Event (triggered by bill_generated) or Audience Qualification.

6. How It All Connects — Your Capstone Flow

Audience Compositions

When you click Create Audience in AEP, you see two options:

1. Build rule — Segment Builder (what we discussed)
2. Compose audience — Audience Composition

Here's the difference:

Build Rule (Segment Builder)

• Define rules based on profile attributes and events
• Example: "Customers where eventType = bill_generated AND no payment_received"
• Produces a single audience from raw data
• Supports streaming (real-time) evaluation

Compose Audience (Composition)

• Combines existing audiences using set operations
• Think of it as working with audiences as building blocks
• Does NOT read raw profile/event data directly — it works with already-built audiences

Composition building blocks:

7. Key AJO Terms Quick Reference

The post Segments vs Audiences first appeared on Moses Dinakaran.

A merge policy tells AEP how to assemble one person's profile from multiple data sources.

Why it exists

One customer can have data spread across many datasets:

Dataset 1 (CRM)      → Alice, email, account status

Dataset 2 (Billing)  → Alice, bill amount, due date

Dataset 3 (Usage)    → Alice, 9.2 GB used, 92%

AEP needs rules to merge these into one unified profile. That's the merge policy.

What it controls (3 things)

Simple analogy

Think of building a puzzle of a person:

• Datasets = puzzle pieces from different boxes
• Merge policy = the instructions that say:
• Which boxes to use (dataset selection)
• If two pieces overlap, which goes on top (attribute merge)
• How to know two pieces belong to the same puzzle (ID stitching)

How data gets from Dataset to Profile

When you ingested Alice's record, here's what happened behind the scenes:

Dataset vs Profile — what's the difference?

Example: If you had 3 datasets about Alice:

• customer_profile dataset → name, account, billing
• usage_events dataset → data usage records
• support_tickets dataset → support call history

The Profile for CUST001 would combine ALL of them into one unified view of Alice.

What is a Merge Policy?

Since a Profile is assembled from multiple datasets, AEP needs rules for:

1. Which datasets to include — maybe you only want certain datasets in the profile
2. How to handle conflicts — if two datasets have different values for the same field, which one wins?

That's what a Merge Policy defines:

Merge Policy = "Rules for how to assemble a profile from multiple datasets"

The two key settings:

1. Attribute Merge (how to handle conflicts):

Example: If dataset A says accountStatus = "active" (updated yesterday) and dataset B says accountStatus = "suspended" (updated today):

• Timestamp ordered → picks "suspended" (newer)
• Dataset precedence → picks whichever dataset you ranked higher

2. ID Stitching (how to link identities):

Method	How it works
None	Only match on exact same identity
Private Graph	Use the Identity Graph to link related identities (CUST001  alice@citisignal.com  +15551230001)

Why you couldn't see Alice in Profiles

You ingested data → Data Lake ✓ → Profile Store ✓

                                          ↓

                                   But when you Browse...

                                          ↓

                              AEP asks: "Which merge policy?"

                                          ↓

                              The DEFAULT merge policy may not

                              include your dataset, or may not

                              know how to find dinakara_customerid

Bottom line: Your data IS in the Profile Store. The merge policy just controls which "lens" you use to view it. Now try Profiles → Browse with the Default Timebased merge policy, namespace dinakara_customerid, value CUST001 — and let me know if Alice shows up.

The post Merge Policy first appeared on Moses Dinakaran.

1. What is Query Service?

Query Service is Adobe Experience Platform’s SQL engine that lets you query and transform data stored in the AEP Data Lake.

• Uses ANSI SQL
• Works on datasets (Parquet files + XDM schemas)
• Designed for analytics and transformation, not transactions

Important mental model: AEP is a data lake, not a traditional database.

2. Key Doubt #1

“If data already exists, why do we need CREATE TABLE?”

Answer:

A simple SELECT:

• Scans raw data files
• Returns temporary results
• Nothing is stored or reused

SELECT * FROM web_events;

A CTAS (CREATE TABLE AS SELECT):

• Runs the query
• Materializes the result
• Saves it as a new dataset in AEP

CREATE TABLE derived_events AS
SELECT * FROM web_events;

This is required because AEP does not store query results automatically.

3. What is CTAS?

CTAS (Create Table As Select) is the mechanism used to create Derived Datasets.

• Output = new dataset
• Stored in the Data Lake
• Reusable, faster, cheaper for repeated queries

Derived Dataset = Result of a CTAS query

4. What is a Derived Dataset?

A Derived Dataset is:

• A dataset created from other datasets
• Cleaned, flattened, aggregated
• Used for analytics, BI, ML, or Profile ingestion

Why it exists:

• Raw XDM data is large, nested, and expensive to query repeatedly
• Derived datasets optimize performance and cost

5. What Query Service Can Do (Alone)

With Query Service only, you can:

• Explore data (SELECT)
• Clean, shape, and manipulate data
• Create one-time derived datasets using CTAS

Technically capable
Not operational or automated

6. What is Data Distiller?

Data Distiller is a licensed add-on that builds on Query Service to support production-grade data preparation.

Data Distiller does not add new SQL.
It adds automation, scheduling, and incremental processing.

7. Key Doubt #2

“Can’t we do all this with Query Service?”

Correct answer:

• Yes, functionally
• No, operationally

Capability	Query Service	Data Distiller
SQL transformations
CTAS	(manual)
Scheduled execution
Incremental processing
Production pipelines
Reliable Profile feeding

8. Why Data Distiller Exists

Adobe introduced Data Distiller because customers needed:

• Repeated transformations
• Cost-efficient processing
• Reliable datasets for Profile & Analytics
• Automated pipelines

Query Service alone is interactive
Data Distiller is operational

9. Relationship Summary

Query Service = SQL engine
CTAS = Mechanism
Derived Dataset = Output
Data Distiller = Automation + Scheduling + Incremental logic

10. One-Line Takeaways (Most Important)

• Query Service answers questions
• CTAS saves answers
• Derived datasets avoid repeated heavy queries
• Data Distiller productionizes Query Service
• AEP is a data lake, not a traditional database

11. When to Use What

Use Query Service only when:

• Exploring data
• Debugging ingestion
• Running one-off analysis

Use Data Distiller when:

• Data feeds Profile or analytics continuously
• Queries must run repeatedly
• Cost, scale, and reliability matter

Scenario	Use Query Service
SQL-based analysis
Large-scale transformations
Real-time personalization
Marketing dashboards	(Prefer CJA)

Data Sources
   ↓
AEP Ingestion
   ↓
AEP Data Lake (Parquet + XDM)
   ↓
Query Service (SQL Engine)
   ↓
Results / Derived Datasets / BI Tools

How it relates to Query Service

Data Distiller uses Query Service under the hood

The post Adobe Experience Platform – Query Service & Data Distiller first appeared on Moses Dinakaran.

• Data is first collected on the client side (website or mobile app).
• That data is sent to Adobe Edge, which is the entry point into Adobe’s ecosystem.
• Traditionally, Edge sends data to Adobe tools like AEP, Analytics, Audience Manager, or Target.
• With Event Forwarding, you can now:
  • Listen to incoming events at the Edge
  • Apply rules and data elements (similar to client-side properties)
  • Forward data to Adobe destinations or external systems via webhooks (e.g., data lakes, decisioning engines, third-party apps)

Key benefit:
Event Forwarding enables server-side, flexible, and secure data routing, reducing client-side complexity and allowing real-time integrations beyond Adobe’s ecosystem.

The post AEP Data Collection first appeared on Moses Dinakaran.

The post Real-Time Customer Profile first appeared on Moses Dinakaran.

• Business Analytics: Focuses on using data (including Big Data) to understand strategic risks and opportunities. It is a key part of Business Intelligence (BI). This is where the "four types" framework is applied.
• Data Analytics: A broader, more technical field concerned with the foundational work of sorting, storing, cleansing, and transforming massive datasets (the work of data scientists).

2. The Four Types of Business Analytics:
This is a maturity model for how organizations use data:

• Descriptive ("What happened?"): Uses historical data to identify trends.
• Diagnostic ("Why did it happen?"): Finds root causes and correlations behind outcomes.
• Predictive ("What might happen?"): Uses historical data and ML/AI to forecast future probabilities (e.g., customer churn).
• Prescriptive ("What should we do?"): An advanced form that uses ML/AI to recommend specific actions to achieve optimal outcomes (e.g., improving retail margins).

3. Adobe Analytics' Role:
Adobe Analytics is the platform that enables this entire workflow.

• It collects data from multi-channel customer journeys (web, mobile, CRM, offline, etc.).
• It provides the tools for analysis (like Analysis Workspace) where marketers perform descriptive and diagnostic analysis to "tell stories" with data.
• It generates actionable outputs (segments, predictive scores) that feed into predictive and prescriptive actions, such as personalization in Adobe Target or advanced attribution modeling.

Conclusion: Analytics is the practice of turning data into insights and actions. Business Analytics provides the strategic framework (the four types), and platforms like Adobe Analytics provide the technical capability to execute that framework from data collection to prescriptive action.

The post AEP : Adobe Analytics first appeared on Moses Dinakaran.

Think of it as solving a puzzle where each piece is a separate clue about a customer from different places (website, app, in-store). The Identity Service finds how these pieces fit together by linking different IDs (like email, CRM ID, device ID) that all belong to the same person. This linking creates a map of relationships called an Identity Graph.

Here’s how it works in three key steps:

Why This Matters

This service solves the common problem of data being stuck in separate "silos" (like CRM, website, app data). By linking identities, you can create a Real-time Customer Profile, which is a single, complete view of each customer. This unified view allows you to personalize their experience seamlessly across all your brand's touchpoints.

Imagine you're a detective trying to solve the mystery of "Who is Customer X?"

You have clues scattered in different notebooks: one notebook has a customer's email address from your online store, another has their phone number from a support call, and a third has their loyalty card ID from in-store purchases.

Your job is to figure out that alice@email.com, (555) 123-4567, and LoyaltyMember#88241 are all the same person—Alice. Adobe Experience Platform's Identity Service is your high-tech system for doing exactly that.

Here’s how it works, broken down into three simple steps with examples:

Step 1: Label the Clues (Label Data as Identities)

This is where you tell the system, "Hey, this piece of information is a unique clue to someone's identity."

• Example: In your "Online Store" notebook (dataset), you mark the Email field as an "Identity." In your "Loyalty Program" notebook, you mark the Loyalty Card Number as an "Identity."
• The Key Choice - Namespace: A namespace is just the type of clue. Is it an Email? A Phone Number? A CRM ID? You pick the right type so the system knows how to handle it.
• The Special Clue - Primary Identity: You pick one main clue per notebook that is the most reliable. For your "CRM System" notebook, the best, most consistent clue might be the crm_id. This becomes the primary key to find that person's main profile.

Important: Just like a real detective, you must work with your legal/privacy team. Decide which clues you are allowed to collect and connect, respecting customer privacy.

Step 2: Combine the Notebooks (Ingest Identity Data)

Now, you feed all your notebooks (datasets) into the detective's system (Adobe Experience Platform).

• Example: You upload the data from your Online Store, your CRM, and your Loyalty Program. Because you already labeled the clues (Email in one, Loyalty ID in another), the system gets to work.
• The Magic (Private Graph): The system sees that alice@email.com (from an online order) is linked to LoyaltyMember#88241 (from a store purchase) because they appeared together on a single receipt. It creates a hidden, connected web—a private identity graph—showing these are the same person. Alice's profile is no longer three separate fragments; it's starting to unify.

Step 3: Check Your Work (Verify the Data)

Finally, you check the system's case files to confirm the connections were made.

• Example: You go to the Identities page in Adobe, look up alice@email.com, and the system shows you all the other connected IDs (phone, loyalty ID) that are now stitched to her single customer profile. You've successfully solved the mystery!

Real-World Analogy: The Hospital System

Think of a modern hospital with different departments:

• The Emergency Room knows you by your Driver's License.
• The Lab knows you by your Lab Order ID.
• The Billing Department knows you by your Account Number.

A good hospital system labels these IDs, ingests records from all departments, and uses an Identity Graph to link them all to you, the single patient. This way, any doctor can see your complete history, no matter which department you visited first.

Summary in One Sentence:

You tell the system which data points are customer IDs (label), send in your customer data (ingest), and check that the system correctly linked everything (verify) to build a complete, single view of each customer.

Identity Graph Viewer

Identity Graph Viewer in Adobe Experience Platform. It's a tool designed for data engineers to inspect and debug how customer identities are connected, or "stitched" together.

Think of it as a "debugging window" that makes the invisible process of identity stitching visible and easy to understand. Before this tool, the process was essentially a "black box" for engineers, making it hard to validate if data was ingested correctly or to find errors in profile unification.

Here are the tool's key features:

• Search & Explore: You can search for a specific identity (like an email or CRM ID) and see a graphical map of all its linked identities.
• Visual Graph View: The main display is a visual graph where each circle (node) is an identity (e.g., email, phone, device ID) and the connecting lines show how they are linked.
• Debug with Details: Clicking on any identity node or connection line reveals detailed metadata. This includes which datasets created the link, batch IDs, and timestamps, helping you trace the source of any data or stitching issue.
• Data Source Timeline: A separate tab shows a timeline of all data sources ingested, allowing you to see exactly when and how new data contributed to building or changing the graph.

How It Solves Real Problems

The tool is especially useful for two critical scenarios:

1. Validation: After ingesting new data, you can check if identities are stitching together as expected.
2. Debugging: If you suspect an error—such as two unrelated customer profiles being incorrectly linked—you can use the visual graph to spot these "collapsed" clusters and investigate the specific data batches that caused the connection.

The post AEP : Identity and identity graphs  first appeared on Moses Dinakaran.

An XDM schema is constructed from four main building blocks, which determine its structure, purpose, and the type of data it will contain. You can think of these as a hierarchy, from the most general to the most specific, working together to model your customer data.

Here's an overview of these components, starting from the top of the schema:

How These Blocks Work Together

Schema = Class + Field Groups. You can think of building a schema this way:

1. Choose a Class: First, select a class (e.g., "XDM Individual Profile" with Record behavior, or "XDM ExperienceEvent" with Time-series behavior). This sets the schema's core purpose and provides essential base fields.
2. Add Field Groups: Then, add relevant field groups to include all the specific data points you need. For example, add a "Demographic Details" field group to a profile class.
3. Fields and Data Types: Within the chosen class and field groups, you will find all the necessary data types and individual fields. You can also create custom data types and field groups.

Key Standard Classes Explained

These two classes handle 90% of customer data use cases:

XDM Individual Profile (Record Behavior)

Think of this as a digital dossier or customer ID card.

• For: Data about who a customer is
• Data Pattern: Singular & updatable (one profile per customer that changes over time)
• Examples:
  • Name, birthday, loyalty tier
  • Contact info (email, phone)
  • Lifetime value, segment memberships
• Analogy: A customer database row that gets updated

XDM ExperienceEvent (Time-series Behavior)

Think of this as a detailed activity log or customer diary.

• For: Data about what a customer does
• Data Pattern: Multiple & immutable (many events per customer, added over time)
• Examples:
  • Website page view (timestamp, page URL)
  • "Add to cart" action (product, quantity)
  • Purchase transaction (amount, items, payment method)
  • Email open, call center interaction
• Analogy: A stream of timestamped events that can't be changed, only added to

Real-World Example: A Coffee Shop App

Let's see how these work together for "CoffeeCo's" loyalty app:

Profile Schema (XDM Individual Profile)

• Class: XDM Individual Profile
• Field Groups:
  • Demographic Details → Name, birth date
  • Personal Contact Details → Email, mobile number
  • Loyalty Details → Member ID, points balance, tier (Gold)

Event Schemas (XDM ExperienceEvent)

• Class: XDM ExperienceEvent
• Field Groups (varies by event):
  • App Interaction → Opened app, viewed menu
  • Commerce Details → Ordered latte ($5.50), used 50 points
  • Location Details → Visited "CoffeeCo Downtown" store

The Magic: The platform automatically links all events to the correct profile using a shared identifier (like email or loyalty ID), building a complete customer journey.

Quick-Reference Cheat Sheet

Remember This

1. Start with your question: Need to track attributes? Use Profile. Need to track actions? Use ExperienceEvent.
2. They work together: Profiles are built from events. A profile without events is just a static record.
3. Use field groups: Don't build from scratch—use Adobe's pre-built field groups whenever possible.
4. Think in timelines: A complete customer view = Profile (who they are) + ExperienceEvents (what they've done over time).

This structure allows Adobe Experience Platform to unify data from all sources (web, app, store, call center) into a single, actionable customer profile for personalization and analytics.

The post AEP - Schema building blocks first appeared on Moses Dinakaran.

Core Architecture of Adobe Experience Platform

• Built on a scalable cloud infrastructure, optimized for speed and flexibility, using streaming technologies, edge networks, Kafka pipelines, and NoSQL databases.
• Uses a common, open data language called Experience Data Model (XDM), enabling seamless communication across systems and teams.
• Provides open connectors to:
  • Ingest data from multiple sources (web, mobile, CRM, POS, call centers, warehouses, etc.)
  • Activate data back into marketing and engagement systems.

Key Platform Services

• Identity Service: Stitches data from multiple systems into a 360° customer profile.
• Segmentation Service: Creates dynamic audiences using drag-and-drop tools.
• Data Governance Service: Ensures compliance, consent, and trusted data usage.
• Intelligence Services: Provides AI/ML capabilities such as propensity scoring, look-alike modeling, and predictive insights.

Native Applications Built on AEP

1. Real-Time Customer Data Platform (CDP)
   • Builds unified customer profiles
   • Creates actionable, dynamic audiences
   • Activates personalization across channels in real time
2. Adobe Journey Optimizer
   • Enables real-time, one-to-one, omnichannel customer journeys
   • Uses visual journey orchestration and automated messaging
3. Customer Journey Analytics
   • Analyzes customer behavior across offline and online channels
   • Helps marketers understand journeys, trends, and optimize experiences
4. Adobe Mix Modeler
   • Uses AI-powered forecasting and multi-channel optimization
   • Measures marketing effectiveness and maximizes ROI on budget spend

AEP Architecture Diagram

Ref : https://experienceleague.adobe.com/en/docs/blueprints-learn/architecture/architecture-overview/platform-applications

The post Adobe Experience Platform (AEP) first appeared on Moses Dinakaran.