Adobe Analytics to Customer Journey Analytics: move or self-host

What the constraint requires from an analytics platform

Whatever platform you choose, the EU consent rules and transfer rules decide what it may collect and where it may send data. These cards set out the requirements that shape the move or self-host choice, and what to check before you re-implement.

How CJA, Matomo and PostHog meet the constraint

Option comparison: fit, gaps and trade-offs

This table compares Customer Journey Analytics with self-hosted Matomo and PostHog, plus the hosted versions of the two open-source options, on residency and consent fit, known gaps and who supports each. Test each row against your own consent setup, history needs and data location requirements. The main takeaway is that self-hosting keeps data in your infrastructure but moves consent configuration, history import and support work to your team or a partner.

What to export from data feeds before retention runs out

This sequence leaves you with a complete, documented copy of your Adobe Analytics data before the retention deadline in your contract, so the team can rebuild history in CJA, Matomo or PostHog on its own schedule. It also keeps the raw events that aggregated imports cannot carry over.

1. Confirm the retention deadline in writing

   Ask your Adobe account team and procurement to confirm, in writing, the date after which Adobe Analytics data is deleted, and whether that date differs by report suite or contract. Check whether the contract includes a retention extension and what it costs. Record the owner, the date and the source document in the migration plan. This step is done when a named person has signed the date and every later step is scheduled against it.

2. Enable raw data feeds to storage you control

   Ask Adobe which data feed cadence is available to your organization, such as hourly or daily delivery, and request delivery to a cloud storage location that your team owns and administers. Confirm the file format, folder structure and any naming convention with Adobe in writing. Your cloud or platform team should verify that the first files arrive in your bucket and that they match the expected report suites. This step is done when several consecutive files have landed and been checked.

3. Request the historical raw export

   Ask Adobe whether a historical raw export is available for the report suites you need, and confirm the scope, delivery method and any cost before the retention deadline. Prioritize the report suites that hold your highest-value history, such as checkout, lead and core content traffic. Your team should confirm the date range that Adobe will deliver and whether any part of it is excluded. This step is done when Adobe has confirmed the range in writing and the files are in your storage.

4. Export Data Warehouse reports on a schedule

   Set up scheduled Data Warehouse report exports for the summary reports your business reviews, such as traffic sources, conversion and campaign performance. Confirm any delivery limits in the Adobe documentation or with your account team, because large reports can be split or truncated. Store these exports alongside the raw feeds so that summary numbers can be reconciled later. This step is done when each scheduled report has delivered at least one complete export to your storage.

5. Document props, eVars and events

   Write a versioned data dictionary that maps every prop, eVar, event and list variable to its business meaning, its implementation owner and the date it was introduced or changed. Include processing rules, classifications, virtual report suites, time zone and currency settings, and any tag manager rules that set these variables. Without this record, raw hit columns are difficult to interpret after the Adobe contract ends. This step is done when an analyst who did not build the implementation can explain each variable from the document alone.

6. Archive raw files with access controls

   Store the raw files, Data Warehouse exports and data dictionary in a location with encryption, restricted access and logged reads, and apply a retention policy that your legal and privacy teams approve. Generate checksums for each file so that later copies can be verified. Restore a sample of files to a separate environment to confirm that they can be read and parsed. This step is done when the restore test passes and the access list is approved by the data owner.

7. Decide which raw features you need later

   Decide which features need raw event data, such as the Visitor Log, segmentation on individual visits or custom analysis of path sequences. Matomo's Google Analytics importer brings over aggregated report data only, so these features do not work on imported history, as the Matomo FAQ on import limitations explains for that importer. If you need these features on past data, keep the raw files and plan a replay into the new platform. This step is done when the decision is recorded and linked to the archive location.

8. Reconcile sample totals before the deadline

   Choose a sample period and compare visit, pageview and conversion totals computed from the raw files with the figures in Adobe Analytics for the same report suite and time zone. Investigate any differences, such as bot filtering, processing rules or late-arriving data, and document the cause. Repeat the check for a second period that includes a campaign or seasonal peak. This step is done when the variances are explained in writing and the data owner signs off before the retention deadline.

How to deploy self-hosted Matomo or PostHog under the constraint

This sequence takes the team from a confirmed platform choice to a running, configured instance in a region the organization can justify, with consent-relevant settings applied before any production traffic is collected. Each step closes with a check the team can verify.

1. Choose the platform and release against the constraint

   The platform owner, usually the analytics lead with the privacy office, decides between Matomo and PostHog based on the use case: Matomo for web audience measurement, PostHog for product analytics, session replay and flags. For Matomo, compare Matomo 5 with the Matomo 6.0.0 beta, which the changelog lists as in beta, and do not run a beta in production without a documented reason. Confirm current versions with the vendor before installing. The output is a short decision record naming the platform, release line and the reason for it.

2. Confirm PHP and database versions for the release

   The infrastructure team checks the runtime against the requirements FAQ. Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer. Matomo 4.16 and 5 run on PHP 8 with MySQL 5.5 or later or MariaDB, behind a web server such as Apache, Nginx, IIS or LiteSpeed. Confirm the exact minimums with the vendor, since they may change between releases. The output is a signed-off stack list, with each version pinned, that the platform team can reproduce in staging.

3. Size application and database servers by pageviews

   Estimate monthly pageviews from current analytics and the expected growth, then size the servers. Matomo's requirements FAQ sizes a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month, and recommends separate app and database servers with 8 CPUs and 16 GB of RAM each for up to 10 million pageviews a month. PostHog's self-host docs recommend a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment. The output is an infrastructure request that cites these figures and the traffic estimate behind them.

4. Place the instance in the required region

   The data protection lead confirms where personal data must sit and where the instance will run. Self-hosting means the organization chooses the cloud account, data center or on-premises location, so residency is set here rather than inherited from a vendor. For PostHog Cloud comparisons, the managed options are US (Virginia) and EU (Frankfurt), but this sequence assumes a self-hosted instance in a location the team controls. Record the region, the backup location and the administrators' access locations. The output is a data map entry that the privacy office can review.

5. Install the chosen platform in a staging environment

   For Matomo, the platform engineer installs the On-Premise Community edition on the pinned stack and completes the web installer. For PostHog, the team chooses between the free Docker Compose hobby deployment under the MIT license, installed with the deploy-hobby script, and a paid license if the ee directory features are required. PostHog states that its self-hosted deployments are officially unsupported and that it offers no customer support for them, so the team must own that operational risk. The output is a working staging instance with a test site or project that accepts events.

6. Configure IP truncation and tracker lifetime

   Before production collection, the analytics engineer applies the privacy settings the consent position depends on. CNIL's sheet 16 lists truncating the last byte of the IP address and a tracker lifetime of at most 13 months as conditions for the consent exemption, along with limiting purposes to audience measurement and A/B testing. Matomo's ePrivacy FAQ notes that adding User ID, heatmaps or session recordings removes that exemption, so those features stay off in this configuration. Confirm the current exemption criteria with the relevant authority. The output is a configuration record listing each setting and its value, reviewed by counsel.

7. Validate tracking and retention before go-live

   The QA lead sends test traffic through the staging site and confirms that events arrive, that IP addresses are truncated in stored data, and that cookies expire within the configured lifetime. The team also records a backup and restore test, because the vendor is not the party that will recover the data. Where historical data is being imported, confirm which features will not work on it, for example Matomo's Visitor Log and segmentation on imported reports. The output is a signed test report that the platform owner approves before the production tag is switched.

Questions buyers ask before choosing between CJA and self-hosting

Evidence auditors and regulators ask for

Whichever destination you choose, an assessor will ask the same questions about consent, retention, transfers and access. These cards describe the records to prepare so the answers come from documents rather than memory. They are inputs prepared for an assessor, not certifications or audit reports.