Customer Journey Analytics RFP Template

Before You Issue a Customer Journey Analytics RFP

CJA projects succeed or fail on decisions made before any dashboard exists: how identity is stitched across datasets, how XDM schemas are modeled, and which historical data is worth bringing forward. An RFP that jumps straight to “rebuild our reports in CJA” skips the part where most of the risk lives. Make vendors explain their identity strategy in writing — which namespaces, which stitching method, and what happens to visitors who never authenticate.

If you are migrating from traditional Adobe Analytics, insist on a reporting-parity plan with named metrics. Teams tolerate a new tool; they do not tolerate numbers that no longer match what they reported to the board last quarter. A credible partner will propose a reconciliation window where both systems run side by side, with documented explanations for every expected variance.

What the Customer Journey Analytics Sections Cover

• Datasets in scope and the backfill window you fund
• Person ID choice and the stitching rules behind it
• Data view logic replacing old report suite settings
• Agreed tolerance when CJA and Analytics numbers differ
• Connection sizing and its effect on Platform consumption
• Who rebuilds each legacy Workspace project

Writing the Customer Journey Analytics Scope of Work

Scope CJA as three separable layers and price them separately: the datasets landing in Experience Platform, the connection that binds them, and the data views analysts actually work in. Most confusion in CJA proposals comes from collapsing these. Say which datasets exist today, which must be built, and which are someone else's responsibility to deliver. If call-center, loyalty or transactional data is expected to appear in the connection, name the system, the owner and the delivery mechanism, because a dataset that has to be negotiated out of another department is a schedule risk, not a technical one.

Define the identity work precisely enough to price it. The scope should state which namespaces are authoritative, whether you need field-based stitching for unauthenticated web behavior, and what the expected authentication rate is on each surface. It should also say what happens to the long tail of visitors who never identify themselves, because the decision to include or exclude them changes every people-level metric in the platform. If you have an existing Real-Time CDP identity graph, say whether CJA is expected to reuse it or to stand up its own stitching.

Treat the data view layer as a deliverable with its own acceptance, not as configuration done in passing. Component naming, derived fields, session timeout rules, attribution defaults and filtered views for different business units are where analysts either adopt the platform or abandon it. State how many data views you expect, who owns them after handover, and whether business-unit-specific views are in scope. Also state your position on historical backfill in months, not in aspirations, since backfill volume drives both cost and elapsed time far more than report complexity does.

The out-of-scope list should be unusually explicit here. Name what is not included: rebuilding every legacy Analysis Workspace project, retiring the source Adobe Analytics implementation, Experience Platform sandbox governance for other teams, and any activation use case, which belongs to Real-Time CDP rather than CJA. Then define done as agreed numbers rather than delivered screens. A reasonable acceptance criterion is that a named set of metrics reconciles within a stated tolerance against the source systems, with each remaining variance documented and explained rather than argued about.

Requirements That Actually Separate Customer Journey Analytics Proposals

• Stitching design and evidence — require the vendor to state which stitching approach they recommend for your authentication profile, what match rate they expect, and how they will measure it before anyone is asked to trust a people-level metric.
• Dataset contract — ask for the schema, event-time semantics and expected daily row volume of each dataset in the connection, since CJA joins on timestamps and a source that stamps ingest time rather than event time will quietly distort every journey.
• Backfill economics — require a written estimate of backfill volume, elapsed processing time and the storage consequence, plus a recommendation on how far back is genuinely useful given how your business questions decay with age.
• Derived field strategy — ask how much logic they place in derived fields at the data view layer versus fixing it upstream in the dataset, because data view logic is fast to ship, invisible to other tools and easy to duplicate inconsistently.
• Lookup and classification handling — require an approach for lookup datasets covering products, campaigns and store locations, including who maintains them and what happens to reporting when a lookup key arrives late.
• Cross-channel metric definitions — insist on a written definition of what constitutes a session, a person and an engagement once offline and app data are in the same connection, because the defaults will not match what either the web or the CRM team means.
• Access and governance model — ask how sandboxes, data view permissions and field-level restrictions will be configured so that regulated or sensitive fields are not simply visible to every analyst with a license.

Common Mistakes in Customer Journey Analytics RFPs

• ✕ Treating CJA as a reporting migration when it is really a data architecture project with reporting on top.
• ✕ No explicit identity-stitching design, leading to inflated people counts that discredit the platform internally.
• ✕ Migrating every legacy report instead of auditing which of them anyone still reads.
• ✕ Ignoring dataset ingestion costs and retention decisions until the first Experience Platform invoice.
• ✕ No plan for the variance between Analytics and CJA numbers, so stakeholders conclude the new system is broken.

• ✕ Writing the scope around the datasets that are easy to connect rather than the questions the business wants answered, producing a connection rich in web behavior and missing the transactional data every real journey question depends on.
• ✕ Assuming the Adobe Analytics source connector solves data modeling, when it delivers your existing variable sprawl into CJA unchanged and the renaming work simply moves to the data view layer.
• ✕ Omitting a decision on session definitions across channels, so the same customer interaction counts once in web reporting and three times in the cross-channel view without anyone noticing for months.
• ✕ Scoping training for analysts but not for the people who will maintain the connection, leaving nobody internally able to add a dataset or fix a mis-mapped field after handover.

Questions Worth Asking Customer Journey Analytics Vendors

1. Walk through an identity-stitching design you have shipped: namespaces used, stitching method, and the trade-offs you accepted.
2. How do you decide which historical Adobe Analytics data to backfill, and how much did backfill cost on comparable projects?
3. What is your reconciliation process when CJA and traditional Analytics disagree during parallel running?
4. Show an example data view configuration and explain how you kept component naming usable for analysts.
5. How many production CJA implementations has the proposed team delivered end to end — not assisted, delivered?

How to Weight the Customer Journey Analytics Evaluation

Weight data architecture evidence well above reporting craft. Building an attractive Workspace project is a skill most analytics vendors have; designing a connection whose person counts survive scrutiny is not. When you compare proposals, the sections on schema design, identity and dataset contracts should carry more weight than the sample dashboards, because the dashboards can be rebuilt in a week and the architecture cannot.

Give explicit weight to the ability to explain variance. In every CJA program there is a moment when a headline number differs from what the business reported last quarter, and the project survives or dies on whether someone can explain the difference credibly. Proposals that include a structured reconciliation approach, with expected sources of variance named in advance, are managing the real risk. Proposals that promise parity are promising something they cannot deliver.

Weight cost modeling more than you would for a self-contained analytics tool, because CJA sits on Experience Platform and the consumption model rewards discipline about what is ingested and retained. A vendor who has thought about which datasets earn their storage, which can be aggregated before ingestion and what retention each needs is protecting your operating budget, and that judgment deserves scoring weight alongside technical capability.