Interview prep

Bring marketing, IT and privacy together, list business goals, turn each into a named use case, then map the sources, identities, consent and activation channel each one needs.

Score each on data availability, feasibility, business impact and dependencies, then pick the top 3 to 5 that are high value and can run on data you already have.

Push back politely: ingest what the agreed use cases need. Extra data costs licence volume, adds governance risk and slows the build.

Development sandboxes are for building and testing; production sandboxes hold live data that feeds real activation. You build in Dev and promote validated configuration to Prod.

Package them with sandbox tooling, then import the package into the production sandbox and re-run QC there.

Create a role whose permissions cover schema management only and whose sandbox access lists just that sandbox, then assign the user to it.

The namespace is the type or context (Email, CRMID); the value is the actual ID ("a@b.com"). Identity Service needs both to link records.

The Experience Cloud ID: a device/browser identifier set by Web SDK or the ECID service. It identifies anonymous visitors and links to known IDs at login.

No. Several travellers share a PNR and an order is a transaction, so using them as identities would merge different people. Keep them as fields.

Profile for slowly changing attributes such as name, tier and consent; ExperienceEvent for time-stamped actions such as page views, bookings and purchases.

As an ExperienceEvent with an array of segment objects (flight number, origin, destination, date) plus booking-level fields like fare class and total.

Only additive changes: add new fields and field groups. Once a schema has been used to ingest data you cannot remove, rename or change the type of existing fields.

A field group adds a set of fields to a schema of a given class; a data type is a reusable structure (like an address) that you place inside field groups or schemas.

It namespaces your organization's fields so they never collide with Adobe standard fields or other organizations' fields.

Create a custom field group with fields under the tenant object, reusing data types where possible, and document it in the SDR.

A merged view of every Profile-enabled schema of the same class. Segmentation and the profile viewer read the union, not individual schemas.

Identity fields mark specific schema fields with a namespace; identityMap is a flexible map of namespaces to values, used heavily by Web and Mobile SDK events.

It is the key the profile fragment is stored under, so a wrong or shared primary identity breaks profile assembly and can merge people.

The schema is the structure (the blueprint); the dataset is where records that follow that structure are stored.

The data lake keeps all ingested data for Query Service and CJA; the Profile store keeps Profile-enabled data assembled into real-time profiles for segmentation and activation.

Raw logs, high-volume data no audience uses, and anything sensitive that must not be activated. They can still be analysed from the data lake.

Batch is scheduled bulk loads (CRM extracts, warehouse tables) with higher latency; streaming sends records as they happen (web events, booking updates) for near real-time use cases.

Web SDK (usually through Tags) sends XDM events to the Edge Network; the datastream routes them to the AEP dataset and other services like Analytics.

Use a Data Prep calculated field (date functions) in the mapping step so it is converted to the XDM date-time format during ingestion.

Open the dataflow run, read the error diagnostics, check failed rows against the schema (types, required fields, formats), fix mapping or source, then re-run.

An option that ingests the valid rows of a batch and rejects the invalid ones up to an error threshold, instead of failing the whole batch.

Streamed data is available to Profile within minutes; batch data depends on the schedule and processing, so it is slower.

Not directly. Query Service reads datasets in the data lake; profile data can be analysed through profile snapshot exports.

SELECT commerce.order.purchaseID, COUNT(*) FROM orders GROUP BY 1 HAVING COUNT(*) > 1;

Reconcile row counts with the source, check nulls and duplicates on key fields, and spot-check 20 to 30 known customers in the profile viewer.

When an event carries both the ECID and a known ID (e.g. CRMID at login), Identity Service links them in the graph, so earlier anonymous activity joins the known profile.

Shared devices, shared emails and junk values. Prevent it with unique namespaces and namespace priority, and by never sending placeholder IDs.

The graph decides which identities belong to one person; the merge policy decides how their profile fragments and conflicting attribute values are combined.

Signed-off QC in Dev, package and import to Prod, recreate connections, run first Prod loads, reconcile counts, verify profiles and consent, confirm alerts, then hand over runbooks.

Sandbox tooling packages for schemas, datasets and other supported objects, followed by validation in Prod.

Dataflow failures, ingestion lag, profile counts, identity graph health and audience sizes, daily for the first two to four weeks.

The Solution Design Reference: the master document mapping business requirements to Analytics variables, events and implementation details.

Define the KPI, decide the metric (success event) and dimensions (eVars/props) needed to answer it, and document where each is set.

One global suite with virtual report suites is usually easier to govern; separate suites make sense only when data must be kept apart.

A view of an existing report suite filtered by a segment, with its own settings, used to give teams their own reporting without separate data collection.

Data is processed in the suite's time zone and currency; getting them wrong distorts daily trends and revenue.

Pros: one implementation and cross-site view. Cons: shared variable slots and settings must suit every site.

A prop applies only to its own hit; an eVar persists and can take credit for later success events, based on allocation and expiration.

For hit-level values you want to path or correlate, and as a backup copy of an eVar value for hit-level analysis.

A prop that holds several delimited values in one hit, each reported as a separate line item.

Allocation chooses which value gets credit when it changes (most recent, original); expiration decides when the value stops persisting (visit end, a time period, or an event such as purchase).

An eVar that binds its value to products in the products string, so credit is given per product (e.g. which search term found each product bought).

Usually most recent allocation with an expiration of around 30 days or until purchase, matching the attribution window agreed with marketing.

Passing a unique ID with an event so Analytics counts it only once, preventing double counting on page refreshes.

A semicolon-separated string per product: category; product; quantity; price; product-specific events; merchandising eVars. Several products are separated by commas.

Counter adds 1 each time; numeric adds a number you pass (e.g. seats); currency adds a monetary value converted to the suite's currency.

Bot rules filter known and custom bots into bot reports; IP exclusion drops hits from given IP ranges entirely.

Either exclude office IPs (gone from reports, though still in Data Feeds) or flag internal traffic in a variable and filter it with a segment or virtual report suite.

No. Exclusion is not retroactive and excluded hits never return to reports, though they remain in Data Feeds with an exclude_hit flag. Test rules before turning them on.

The Edge Network translates XDM fields into Analytics variables: some automatically, others through the Analytics field group or the data object, plus processing rules.

s.t() sends a page view; s.tl() sends a link-tracking call that does not increment page views.

Most likely two page-view calls per page, for example a rule firing twice or both AppMeasurement and Web SDK sending; confirm in Debugger.

Mapping context data or Web SDK fields to variables, cleaning values and setting variables based on conditions, without changing site code.

No. They run at collection time; to correct history you need classifications or reprocessing approaches.

Processing rules are self-service in the admin console; VISTA rules are server-side rules built by Adobe for more complex logic.

A lookup that adds attributes to a variable's values, for example tracking code to campaign name and channel.

Classifications add reporting metadata and apply to historical data; processing rules change data as it is collected and only going forward.

Use a consistent code naming convention, then upload the classification file to a classification set (or automate it with the API). Plan around the legacy rule builder being deprecated.

Test each SDR requirement in Debugger, check data in Workspace the next day, and reconcile orders and revenue with the backend.

Ad blockers, consent opt-outs, the confirmation page not firing, or bot filtering; quantify the gap and agree an accepted variance.

Experience Platform Debugger, browser developer tools, Assurance for Web SDK, and real-time or Workspace reports.

Hit includes only matching hits; visit includes whole visits containing a match; visitor includes everything from people who ever matched.

A fallout visualization in Workspace with search, select flight, passenger details, payment and confirmation steps.

A calculated metric: Revenue divided by Orders.

Scheduled exports of raw, hit-level Analytics data to cloud storage for analysis in other tools.

Workspace applies processing, bot filtering and visit logic; in feeds you must use post columns and exclude hits yourself to match.

An owner per variable in the SDR, change control for new variables, periodic audits and privacy labels for personal data.

Scraping breaks when the page design changes; a data layer is a stable, documented contract for every value you track.

Pages push event objects to window.adobeDataLayer; listeners (and Tags rules) react to each push, and the layer keeps the full state and history.

Every object (page, user, product, cart, event), each field with type and example, when it is set, and which tag uses it.

Edge Network configuration that receives Web SDK events and forwards them to the services you enable, with the IDs (report suites, sandbox, dataset) for each.

So development and staging traffic goes to test report suites and sandboxes, keeping production data clean.

Yes. The datastream forwards the same event to the Analytics service and the AEP dataset at once.

The container in Tags that holds the configuration for one site or app and is published as a library through environments.

So the dev site loads the dev library and production loads only approved, published code.

Web properties deliver a JavaScript library to browsers; mobile properties configure the Mobile SDK in native apps.

Web SDK sends one XDM call to the Edge Network for every Adobe product; AppMeasurement sends Analytics-only beacons straight to Analytics.

Core. It provides page load, click and custom code events, plus base data element types.

Build the XDM schema and datastream, add the Web SDK extension, map data elements to XDM, run both in parallel and reconcile, then retire the old extension.

A reusable variable in Tags that returns a value from the page, used by rules and extensions.

With _satellite.getVar('Data element name').

It keeps the last value for the page view, session or visitor, so later pages can reuse it when the source is no longer present.

Events that trigger it, conditions and exceptions that filter it, and actions that run, such as sending a Web SDK event.

Give each user action exactly one rule, use precise conditions, and verify in Debugger or Assurance that one beacon fires.

A direct call rule fires on _satellite.track() from site code; a data layer event rule reacts to a push to the data layer. Data layer events keep site code decoupled.

Configure default consent in the extension, then call setConsent with the visitor's choice from the CMP; Web SDK holds or sends data accordingly.

Events are held locally until the visitor makes a choice; they are sent if consent is given and discarded if not. The default setting is "in"; "out" discards everything.

Opt out in each region and confirm in Debugger that no calls fire for the blocked categories, then opt in and confirm they do.

Add changed resources to a library, build it to Development, test, submit to Staging, approve, then publish to Production.

The set of changed rules, data elements and extensions that will be built and deployed together.

The last saved revision is what goes into a library; coordinate through separate libraries and review changes before building.

Use Debugger to inspect the XDM payload of each call, Assurance to follow it through the Edge Network, and check the data lands in the AEP dataset and Analytics.

Turn on Tags debug mode, check the console for the rule's event and conditions, confirm data elements return values, and check the right library is loaded.

Debugger is a browser extension for what the page sends; Assurance is a session-based tool that shows what Adobe received and processed.

Development, then Submitted and built to Staging, then Approved, then Published to Production.

Republish the last good library if it is one of the five most recent (Adobe-managed host, Archive off); otherwise create a new library that reverts the changes. Then fix in Development.

That key rules fire once, beacons reach Edge or Analytics, page speed is unchanged, and no errors appear in the console.

Regular audits against the spec, monitoring for errors and missing data, and a review step in every site release.

Each rule's purpose and owner, firing tests on every template, unused rules and extensions, and consent gating checks.

Check whether the data layer field or page element changed, confirm in Debugger, fix the data element or rule, and annotate the data gap.

Adding points for fit (job title, industry) and behaviour (visits, downloads) to decide when a lead is ready for Sales.

A lead whose combined fit and behaviour score passes a threshold agreed with Sales, plus any required fields.

Handoffs only work if both teams use the same definitions and SLAs.

Workspaces separate programs and assets between teams; partitions separate the people database, e.g. by region.

They cap how many marketing emails a person receives per day and week, protecting engagement and reputation.

Only trained marketing operations users; others build drafts for review.

SPF lists servers allowed to send for your domain; DKIM signs emails so receivers can verify they were not altered.

Links on your own domain look trustworthy and improve deliverability compared with generic tracking domains.

Authentication (SPF, DKIM, DMARC), list quality, complaint and bounce rates, and content.

Marketo's web tracking script that logs page visits and link clicks and ties them to a lead once identified.

By submitting a Marketo form or clicking a tracked link in a Marketo email, which associates the cookie with the lead.

Through Tags with a consent condition, on every page of the site.

A dedicated sync user connects the systems; each sync cycle runs and then pauses five minutes. Leads, contacts and Salesforce campaigns sync both ways; accounts, opportunities and custom objects come from Salesforce only.

Fields to sync and their direction, which records sync, field mappings, and duplicate handling.

It controls exactly what Marketo can see and edit in the CRM and keeps changes traceable.

Standard picklists, normalization campaigns, duplicate management and field ownership rules.

The system that wins when values conflict, e.g. CRM for account owner, Marketo for email engagement.

So scoring and segmentation can use a small set of job levels and functions instead of thousands of free-text titles.

A smart list updates automatically from its rules; a static list is a fixed set of people you add or remove.

Trigger campaigns run for each person when an activity happens; batch campaigns run for everyone matching the list at a set time.

A set of mutually exclusive segments (e.g. by industry) used to personalize emails and landing pages with dynamic content.

Trigger campaigns that change behaviour and fit scores on activities and data changes, in an operational program.

Reducing behaviour scores over time for inactivity so the score reflects current interest.

Move it to a recycled stage, record the reason, and use the feedback to tune scoring.

Placeholders that insert program values (dates, links) or person fields into emails and pages.

Showing new form questions to returning visitors instead of asking for everything at once.

Send samples, preview with real lead data, check rendering across clients, and verify links and tracking.

A nurture program that sends content in streams on a cadence, moving people between streams as they engage.

Exit rules (e.g. became MQL, opted out) or by running out of content in their stream.

Engagement scores, progression to MQL and SQL, and pipeline influenced.

Run test leads through each flow, check email rendering, CRM sync, scoring changes and unsubscribe handling.

In the lead's activity log and the smart campaign's results tab.

They did not qualify for the smart list, were blocked by communication limits, unsubscribed, or the email bounced.

Consistent statuses (sent, engaged, success) make programs comparable and power attribution reporting.

MQL-to-SQL conversion, pipeline created and revenue influenced by programs.

The Marketo source connector brings people and activities into AEP, and audiences can flow back to Marketo.

Validated schemas and identities, Profile-enabled datasets with data flowing, merge policies agreed, and consent attributes populated.

RTCDP is an application built on AEP: it uses AEP's profiles and identity graph to build audiences and activate them to destinations.

Over-merged identity graphs, the wrong merge policy, duplicate datasets, or a missing exclusion such as consent.

Capture consent in the profile, then enforce it with consent policies where licensed, or exclude non-consented profiles in every audience used for activation.

Opt-in regions need explicit consent before marketing; opt-out regions allow it until the person objects. Store region and consent status so audiences can apply the right rule.

In consent and preference fields on the profile (for example the Consents and Preferences field group), updated from the CMP or preference centre.

Rules for assembling a profile: whether to stitch identities via the graph, and how to resolve conflicting attribute values from different datasets.

Timestamp ordered keeps the most recently updated value; dataset precedence trusts datasets in the order you rank them (e.g. CRM over web forms).

When each identity must stay separate, for example in regulated cases where profiles must not be joined through the graph.

People with an add-to-cart event in the last hour and no purchase event after it, excluding anyone without marketing consent.

Attributes describe who someone is (tier, country); events describe what they did (searched, purchased), usually with a time window.

Check the estimated size against benchmarks, inspect sample profiles that qualify, and test with a small export.

Batch: scheduled, all rule types. Streaming: near real time on incoming events, with rule limits. Edge: instant decisions at the edge for web personalization, with stricter limits.

Streaming (or an AJO event-triggered journey), because the message is only useful within minutes.

Its rules use unsupported constructs, such as long multi-event look-backs or certain functions, so it falls back to batch.

A tag on a dataset or field that says how the data may be used, for example a sensitive or contractual restriction.

When you map an audience to a destination, Platform checks the labels on the data involved against the destination's marketing actions and blocks violations.

Deliberately try an activation that should be blocked and confirm the policy stops it.

Streaming sends audience changes continuously (ad platforms, Target); batch exports files on a schedule (cloud storage, email tools).

Ad platforms match on hashed identifiers so raw PII is never shared; Platform can hash on export where supported.

Licence, authentication, identity requirements, required fields, rate limits and the marketing actions to apply.

Select the destination, choose audiences, set schedule, map identities and fields, review governance checks, then activate and monitor the dataflow.

For streaming destinations the exit is sent so the platform can remove the person; for file exports the next file reflects the change.

Through the Target (personalization) destination, which shares audiences with Target via the Edge for on-site personalization.

To catch mapping, hashing and consent errors before thousands of real customers are affected or ad spend is wasted.

Few profiles have the identity the platform needs, emails were not normalised before hashing, or consent excluded most profiles.

Compare the exported file or received audience with expected counts and inspect sample records field by field.

Build a recent-purchaser suppression audience and exclude it from the ad audience before activation.

In the delivery channel, e.g. AJO business rules for email and push, and in the ad platform's own frequency settings.

A rule (or separate audience) that removes certain profiles, such as non-consented or suppressed customers, from an audience before activation.

Destination dataflow success, failures, match rates, audience size trends and governance violations.

Recent ingestion changes, identity graph merges, merge policy changes and whether a source loaded duplicate data.

Audience catalog with owners, destination matrix, governance documentation and runbooks for failed activations.

Headful renders pages in AEM; headless serves structured content (content fragments) over APIs to apps and other front ends.

Site structure, templates, component catalog, content models, languages, integrations and environments.

Use language copies and live copies (multi-site manager) with translation workflows defined up front.

Author is where content is created and reviewed; publish delivers the approved content to visitors.

Adobe's service for managing AEM Cloud Service programs, environments, Git repositories and CI/CD pipelines.

It caches and filters requests in front of the publish tier, protecting it and speeding up delivery.

Commit to the Cloud Manager Git repo (or a linked repo) and run a pipeline that builds, tests, checks quality and deploys.

Full-stack deploys back-end, front-end and web-tier config together (one per environment); front-end pipelines deploy only CSS and JavaScript themes, and several can run at once. There are also web tier config, config (CDN, log forwarding) and Edge Delivery config pipelines.

A Maven template that generates a best-practice AEM project structure with core components.

From a site template or from your project's templates, defining the root, languages and initial pages.

They become URLs; renaming later causes broken links and needs redirects.

A packaged starter for a site: theme, templates and sample content.

Editable templates are built in the template editor by authorized users and can change without code; static templates are defined in code by developers.

A configuration on a template that sets which components are allowed in a container and their design settings.

Lock structural components in the template and allow only approved components through policies.

Adobe-maintained, production-ready components (title, text, image, teaser and more) that projects extend through proxies.

Your project creates a component that inherits from a Core Component, so you get upgrades while customizing.

It exposes CSS-based style variations of a component for authors to choose, without new code.

A Content Fragment is structured content without layout (for any channel); an Experience Fragment is a reusable, designed piece of a page.

Model it as Content Fragments and deliver it through the GraphQL API (headless).

Experience Fragments can be exported to Target as offers for tests and personalization.

A digital asset management system: a single governed library for images, video and documents, used across channels.

By brand, campaign and asset type, with metadata for destination, rights and expiry, and consistent tags.

Automatically generated versions of an asset (sizes, formats) for different uses.

A workflow that routes pages to reviewers and approvers before activation to publish.

It scales and is auditable; individual permissions become impossible to manage.

A mandatory medical/legal review workflow and restricted groups for regulated sections.

Create an Adobe IMS integration and a Tags (Launch) Cloud Services configuration, then apply it to the site so pages load the property.

Core Components can populate the Adobe Client Data Layer, which Tags rules read to send data.

Through the Target integration and Experience Fragment export, so authors' content becomes Target offers.

Content freeze, final QA (accessibility, SEO, performance), redirects, DNS/CDN cutover, cache checks and author training.

Cached content at the dispatcher or CDN; check invalidation and cache rules.

Automated scans plus manual checks of keyboard navigation, alt text, headings and colour contrast against WCAG.

Collect ideas from data and stakeholders, write hypotheses, score them (impact, confidence, effort), check traffic, then schedule.

A specific change, a target audience, an expected effect on a named metric, and the reason you expect it.

Use a sample size calculator with baseline conversion, minimum detectable lift and confidence level.

at.js calls Target directly; Web SDK sends one Edge call that returns Target decisions alongside other services. Web SDK is the strategic path.

Default content renders before Target's changes apply; fix it with a pre-hiding snippet and loading the library early in the head.

Views are triggered on route changes (e.g. triggerView in at.js or the equivalent Web SDK call) so Target applies the right experience.

Properties scope activities to channels or sites; workspaces group properties and users so teams only see and edit their own work.

Only approvers or publishers, after QA sign-off, to avoid untested experiences going live.

Each brand team can work independently without touching another brand's live tests.

Target's own rules (browser, location, parameters), Analytics segments, and AEP/RTCDP audiences shared via the Target destination.

Priority decides which experience a visitor gets; conflicting activities should be resolved before launch.

Share a Gold-tier audience from RTCDP to Target, or use a profile attribute passed in the Target call.

A/B splits traffic randomly to compare experiences; Experience Targeting shows each defined audience its own experience without a random split.

When you want to send more traffic to the winning experience as soon as it starts winning, rather than waiting for a fixed split to finish.

VEC edits the page visually; form-based delivers code or JSON offers to locations, useful for SPAs, apps and server-side.

Without an unchanged baseline you cannot measure lift.

Only if you accept you will not know which change caused the result; otherwise use separate tests or an MVT.

Use the form-based composer or VEC with views, delivering changes when the relevant view loads.

Set the allocation per experience (often 50/50 for two experiences) and the share of the eligible audience entering the activity.

It slows learning about the control and increases risk if the variant is worse; use Auto-Allocate if you want adaptive traffic.

Exclude by audience (IP or internal flag) and use QA links for testing; remember QA hits still reach Analytics when A4T is the reporting source.

Analytics for Target: using Adobe Analytics as the reporting source, so any Analytics metric or segment can be used to analyse the test.

Peeking inflates false positives; run until the planned sample size and full business cycles are reached.

Revenue per visitor, ancillary attach rate and drop-off at payment, to make sure the primary win is not hurting something else.

Use activity QA links for each experience, check rendering on devices, confirm metrics fire in Debugger, and verify audience rules.

Not in Target's live report; QA traffic is kept separate. With A4T, though, QA hits are sent to the live Analytics report suite, so segment them out.

Flicker or a goal metric that never fires, which makes the test unreadable.

Visitors entering each experience, an even split, metrics recording, and no errors or performance drop.

Caching, a broken experience, audience rules or redirect issues; investigate before trusting results.

If it breaks checkout or booking, shows wrong prices, or causes a large drop in a guardrail metric.

Check the primary metric's lift and confidence, confirm sample size, review secondary metrics, then look at key segments.

No. It shows the change does not matter, saving development effort; record it and move on.

Ship it permanently through the site code or keep it in Target as an Experience Targeting activity while development catches up.

A journey orchestrates multi-step, event- or audience-triggered flows per person; a campaign sends one message to an audience on a schedule or via API.

Transactional messages relate to something the customer did or owns (booking, delay) and can go to people who opted out of marketing; marketing messages need marketing consent.

Recovered revenue, conversion rate of entrants, and unsubscribe/complaint rates, compared against a holdout.

Profile-enabled schemas and datasets, a consistent identity namespace, consent attributes, and the events and audiences that trigger journeys.

AJO uses it to find the profile; if the event carries a different identity than the journey expects, the person never enters.

Look up test profiles, send test events and confirm they arrive with the right identity and fields within the expected latency.

With full delegation Adobe manages the DNS records for the subdomain; with CNAME the client keeps DNS and points records to Adobe. Full delegation is simpler to maintain.

Gradually increasing volume from new IPs so mailbox providers learn to trust them, avoiding spam-foldering.

So a marketing campaign's complaints or bounces do not damage delivery of critical transactional messages.

The reusable sending setup for a channel (sender, subdomain, IP pool, message type) that messages and journeys select.

The mobile app configured with the Mobile SDK and push credentials, plus a push channel configuration in AJO.

Use marketing-type configurations, which respect marketing consent, and keep transactional configurations for genuine service messages.

A unitary event triggers a journey for one person; a business event triggers a journey that reads an audience, e.g. everyone booked on a delayed flight.

A business event "flight delayed" with flight number and date, then a Read Audience step to target passengers booked on that flight.

Wrong identity namespace, event ID or rule mismatch, the person is not on a profile-enabled schema, or re-entrance rules block them.

Insert profile or event attributes with the expression editor, add conditional content for segments, and set defaults for missing values.

A change to a shared fragment (like a footer) updates every message that uses it, saving time and keeping content consistent.

Reference attributes from the triggering event, such as flight number or cart items, in the message through the expression editor.

Entry on the cart event, wait one hour, an Optimize (conditions) step for "no purchase since", send email, wait 24 hours, check again, send push, exit on purchase.

Create a new version, edit and test it, then publish; profiles already in the old version finish in that version.

A setting that controls whether a profile can enter the same journey again and the waiting period before it can.

Create business rule sets with channel caps (e.g. three marketing emails a week) and apply them to journeys and campaigns.

Addresses AJO will not send to, such as hard bounces and spam complaints, maintained automatically.

Exclude an "in-trip" audience in the journey condition or audience, and apply frequency rules to marketing only.

Use test profiles in test mode, trigger the entry event, follow each branch, send proofs, and check the journey report.

A profile flagged as a test profile so it can be used in journey test mode and message proofs.

Test mode runs the journey for test profiles and sends real messages to them; dry run uses production data to check paths without sending anything.

Entries, exits, errors per step, delivery and open rates, bounces, complaints and conversions against the KPI.

In CJA or Query Service, using the journey step event and message feedback datasets written to AEP.

Pause or slow sending, check list quality and authentication, clean bounced addresses, and review IP warm-up.

Compare the conversion of people who received it with a randomly held-out control group.

Rules, eligibility and ranking that choose which decision item (offer) to show each person from a catalogue. It replaces the older Decision management (offer decisioning), which is now legacy.

Entry criteria and timing, then subject lines and content via experiments, then channel mix.

Analytics collects and reports web/app data with fixed variables; CJA reports on any AEP dataset across channels, with reporting-time settings and no variable limits.

Cross-channel journeys: e.g. how many travellers searched online, called the contact centre, then booked in the app.

The agreed analysis questions; add only datasets those questions need, since rows count toward the licence.

Event datasets (time-series), profile datasets (attributes per person) and lookup datasets (attributes per key such as product).

CJA joins datasets on the person ID; if web uses ECID and the call centre uses CRMID with no link, journeys cannot be combined.

A dataset that classifies a value, like product SKU to category, joined at reporting time.

The configuration that brings selected AEP datasets into CJA, with a person ID per dataset and import/backfill settings.

The connection decides which data comes in; the data view decides how it is reported (components, sessions, attribution).

Limit datasets and backfill to what the use cases need and monitor ingested rows.

Compare ingested and skipped rows in the connection details with dataset row counts in AEP.

Missing person ID or timestamp, or records outside the import settings.

It depends on ingestion lag; streaming data arrives faster than batch, and recent hours may still be filling in.

A reporting configuration on top of a connection that defines components, sessions, attribution and context.

You can change session timeouts, attribution or component settings and history updates instantly, which Adobe Analytics cannot do for most settings.

Dimensions or metrics created at reporting time with rules and functions, without re-ingesting data.

Set persistence on the component in the data view (e.g. most recent value for the session or a time period).

No fixed eVar/prop slots; any schema field can be a component.

Create a metric component from the purchase event field or an event-type value, with counting settings as needed.

Rewriting the person ID on anonymous events with the known ID once the person is identified, so pre-login behaviour joins the customer.

Field-based uses two fields in the same dataset (device ID and person ID; Select package and up); graph-based uses the AEP identity graph (Prime and up). Both are now enabled self-service in the Connections UI.

Use the Attribution panel or apply different models to metrics side by side in a freeform table.

Event keeps matching rows only; session keeps whole sessions with a match; person keeps everything from people who matched.

A calculated metric: bookings divided by searches, optionally within a session filter.

Different sessions and stitching, data view settings, bot filtering, and data sources included.

A flow or fallout from search to booking to check-in to post-trip survey, broken down by channel.

Share Workspace projects, schedule PDF/CSV deliveries, or export to BI tools such as Tableau.

Tracking retention or repeat behaviour of groups who started in the same period.

By creating audiences in CJA and publishing them to AEP, where RTCDP or AJO can activate them.

Add the journey step event and message feedback datasets to the connection and report on them with conversions.

To see test impact across channels and over longer periods than the test report shows.

Assign data views to product profiles in Admin Console and give users only the profiles they need.

Data dictionary, component naming rules, project catalog, access model and regular usage reviews.

Ingestion lag, skipped rows, data view errors and licence usage.

A client document describing need, scope and evaluation criteria. A response covers understanding of the problem, approach, team, timeline, assumptions and cost.

Sponsor, decision makers, licences and packages, sandboxes, systems in scope, success criteria and the communication cadence.

They decide which features, data volumes and destinations are available, so scoping without them leads to promises the product cannot keep.

An audit of existing tools, tags, data flows, identities, consent and pain points, with evidence such as Debugger captures and data samples.

The target architecture: how data will flow from touchpoints through collection, AEP and applications to activation, plus a capability roadmap.

You confirm what data is allowed (PHI, KYC), required agreements such as a BAA, and access controls before designing anything.

Clear scope and out-of-scope, deliverables tied to milestones, assumptions, client responsibilities, timeline, team and price.

Count sources, schemas, use cases, destinations and environments, apply effort per item from past projects, then add QA, hypercare and contingency.

Log it, assess impact on time and cost, and handle it through a change request rather than absorbing it silently.

The SDR maps business requirements to technical configuration (variables, schemas, fields); the SDD describes the technical design: architecture, data flows, environments, integrations and naming.

The client sponsor and technical owners. Sign-off freezes scope for the build, so later changes go through change control.

Loyalty ID as the main person ID, plus email, phone and ECID; booking references stay as fields, and agents' shared emails are excluded from stitching.

Business users test agreed scenarios against acceptance criteria in a production-like environment, log defects, and sign off when criteria are met.

Cutover steps and owners, timing, rollback plan, communication, smoke tests after launch and who approves go/no-go.

A 2–4 week period of heightened support after go-live where the delivery team monitors daily and fixes issues before steady-state support takes over.

Runbooks, final SDR/SDD, access list, training materials, open backlog and support contacts.

Assess impact, decide fix-forward or rollback with the sponsor, communicate, then run a root-cause review.

WHERE filters rows before grouping; HAVING filters groups after aggregation, e.g. HAVING COUNT(*) > 1 for duplicates.

INNER returns only matching rows; LEFT returns all left-table rows with NULLs where no match exists — useful for finding profiles with no events.

Compare row counts with the source, check null rates on required and identity fields, look for duplicate IDs, and check timestamps fall in the expected range.

With dot notation along the schema path, e.g. person.name.firstName or _tenantId.crmId for custom fields.

It calculates across related rows without collapsing them — e.g. ROW_NUMBER to get each customer’s latest event.

CREATE TABLE AS SELECT writes results to a new dataset, often scheduled, to build derived attributes for segmentation or reporting.

An object is a set of named key–value pairs; an array is an ordered list of values. A customer is an object; their orders are an array.

That it’s valid JSON, field names and types are consistent across records, dates share one format, and every record has the identity field.

Each client field is mapped to an XDM field — standard field groups first, custom fields under _tenantId — during source mapping.

_id, timestamp and eventType, plus identity information (identityMap or an identity field) to attach it to a profile.

A JSON document that describes valid JSON: types, properties, required fields. XDM is built on it.

Authorization (Bearer token), x-api-key, x-gw-ims-org-id, and usually x-sandbox-name.

const can’t be reassigned, let can; both are block-scoped. var is function-scoped and older — avoid it in new code.

=== compares value and type with no conversion; == converts types first. Use === to avoid surprises like "1" == 1.

Use optional chaining and a default (?. and ??), or a try/catch, so missing data returns a safe fallback.

An object for a result that arrives later. alloy("sendEvent") returns one; use .then() or await to handle the response.

When the site needs to trigger tracking explicitly from code (e.g. an SPA view change) with _satellite.track("name").

Enable _satellite.setDebug(true), check the rule’s conditions and consent, look for console errors, and confirm the call in the Network tab or Assurance.

Dimensions are categories you group by (channel, date); measures are numbers you aggregate (visits, revenue).

Calculations at a fixed level of detail independent of the view — FIXED, INCLUDE and EXCLUDE — e.g. first purchase date per customer.

Live queries the source each time (always current, can be slower); an extract is a snapshot copy (fast, needs scheduled refresh).

Date range and time zone, filters/segments applied, metric definitions, and whether the export was sampled or truncated.

Filters, parameters and dashboard actions (filter/highlight actions) so selecting one view updates the others.

Use a warehouse fed by Analytics Data Feeds or AEP dataset exports, then connect Tableau live or via scheduled extracts.