Adobe Analytics vs PostHog: when each option fits
Choose self-hosted PostHog when your team is moving from page-level reporting toward funnels, event-level product questions, session replay and feature flags, and when you have people who can run and troubleshoot the platform. Keep Adobe Analytics when your reporting depends on Adobe Experience Cloud and you want a vendor to answer for the product. The decision turns on four things: how much support you need, how much control you need over data location and retention, which event model fits your questions, and who will operate the platform day to day.
PostHog's core is MIT licensed, but the ee directory is covered by a separate license, and premium features in that directory on a self-hosted instance require a PostHog license. If you need fully free software, the posthog-foss repository is purged of all proprietary code and features, so confirm with your legal team which build you will deploy and whether any feature you depend on lives in ee. PostHog also states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on self-hosted instances. Plan for that gap with internal staff or a support partner before go-live.
PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. Measure your current event volume from the Adobe side, including every tracked interaction you intend to send as an event, before you pick a hosting model. If your volume is well above that guidance, price the Cloud option against the operating cost of a self-hosted cluster, and ask PostHog to confirm which Cloud region (US or EU) meets your residency rules.
Which option fits which scenario
This table maps common Adobe Analytics situations to the better fit between self-hosted PostHog and the alternatives covered in this hub. Read each row against your own traffic, data residency rules and support needs, since the right answer often depends on one constraint rather than overall feature depth.
| Scenario | Better fit | Why |
|---|---|---|
| Event-based product analytics and funnels | PostHog | PostHog is built around an event model with funnels, session replay, feature flags and experiments in one product, which matches teams whose Adobe use has shifted toward product questions. |
| Heavy Adobe Experience Cloud dependencies | Stay on Adobe or confirm integrations first | Analysis Workspace, Adobe's tag and data feed workflows and Experience Cloud links are not replicated by PostHog. Confirm each dependency before deciding. |
| In-house platform engineering with no need for vendor support | PostHog self-hosted (MIT core) | The MIT-licensed core can run on your infrastructure, but PostHog states self-hosted deployments are officially unsupported, so your own team or a partner carries operations. |
| Need for vendor-backed support or SLAs | PostHog Cloud or another supported option | PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. Ask whether a paid platform package fits your support requirement. |
| Regulated data residency in the EU | Self-hosted PostHog in your own region, or Matomo | Self-hosting keeps event data in your chosen location. Confirm that PostHog Cloud's US and EU regions meet your requirements before relying on them. |
| Traffic above the self-host guidance | PostHog Cloud or a sized, supported deployment | PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that. |
| Premium enterprise features on self-hosted PostHog | Confirm license needs first | Features in the ee directory need a PostHog license on self-hosted instances, so a fully free deployment is limited to the posthog-foss scope. |
| Historical Adobe data to keep in the new tool | Plan an export and replay path | PostHog's managed migrations do not cover Adobe Analytics directly, so raw feeds must be transformed and imported. Confirm import limits before scheduling cutover. |
How props, eVars and events map to PostHog events
Adobe Analytics stores most business meaning in props (traffic variables), eVars (conversion variables) and events that are attributed through persistence rules and classification. PostHog has no equivalent of eVar persistence windows or classification uploads. Instead, each captured event carries its own properties, and person and group properties hold attributes that change over time. Analysts therefore need to decide which values belong on the event at capture time and which belong on a person or group profile, and they should write those decisions down before any data is sent. Funnels, retention and paths in PostHog are built from named events, so a metric that relied on a sticky eVar must be rebuilt as an explicit event property or a person property.
- Persistence rules: eVar expiration settings have no direct setting in PostHog, so decide whether each attribute is per event, per session or per person.
- Classifications: Adobe classification uploads become properties or lookups maintained in your own pipeline, so confirm who owns that mapping.
- Event naming: Adobe numbered events (for example, event slots) must become descriptive event names with a stable property set.
- Attribution: Adobe attribution models do not carry over, so define the attribution logic in your analysis layer.
- Historical comparability: imported history may not match new definitions, so label any metric that changes meaning.
Check every Adobe report you still use against a documented PostHog definition before you retire it.
Developers own the code that fires events, so they carry most of the rebuild. Adobe implementations often rely on a global data object, s-code style variables and tag-manager rules that set props and eVars on each page view. In PostHog, the SDK captures events and accepts a properties object per call, and the instrumentation lives in application code or in a tag manager that calls the SDK. Developers should replace implicit page-level variable assignment with explicit calls that send the properties each event needs, and they should version the event schema so that changes can be tracked.
- Event schema: define a typed schema for each event and property name, and keep it in version control.
- Identity: decide when to call identify and how anonymous visitors merge into known users, since this replaces Adobe's visitor ID logic.
- Single page apps: confirm how route changes generate pageview events, because automatic capture does not match every framework.
- Consent gating: load the SDK only when your consent configuration allows it, and test the no-consent path.
- Testing: verify each event in a staging project before release, and compare counts with the existing Adobe implementation for a fixed period.
Review the schema with analysts before any release, because a renamed property silently breaks saved insights.
Marketing operations usually manages the tag container, campaign tracking parameters and conversion definitions that depend on Adobe's variable model. Many of those tags pass campaign codes into eVars or props that feed attribution reports. In PostHog, campaign parameters are captured as event or session properties, and conversion goals become events or funnels. Marketing operations should map each existing tag and campaign parameter to a PostHog property or event, then confirm the mapping with analysts. Tags that set Adobe-only variables, such as those for report suites or attribution classifications, have no PostHog counterpart and should be removed rather than translated.
- Campaign parameters: confirm which UTM values are captured as properties and how they persist across a session.
- Conversion definitions: rewrite each Adobe success event as a named PostHog event with a clear trigger.
- Tag inventory: list every tag that writes to Adobe variables and mark each one as keep, replace or retire.
- Consent signals: pass consent state to the tag container so that analytics events stop when consent is withdrawn.
- Parallel running: keep both implementations live for a defined overlap, then compare conversion counts before switching.
Ask your implementation partner or PostHog contact to confirm how campaign properties are stored before you commit to a naming convention.
Where the data lives and who controls it
Moving from Adobe Analytics to PostHog changes where event data sits, who operates it and which legal bases apply. The cards below separate the self-hosted path from PostHog Cloud and set out the questions your auditor and legal team must answer before any tag goes live.
Self-hosted PostHog in your infrastructure
With self-hosting, events, session recordings and feature flag data are stored in servers or cloud accounts you control, so no third-party processor holds them by default. The trade-off is that your team operates the stack, applies upgrades and handles backups. Confirm which hosting location and network path your data protection policy approves, and who holds administrative access to the database and object storage.
PostHog Cloud US and EU regions
PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt). Region selection is set when the project is created, so decide it before instrumenting Adobe replacement tags. Ask PostHog in writing which region your project uses, where backups and support access are located, and how a region move would be handled if one were ever needed.
Adobe hosting and retention terms
Adobe Analytics data sits in Adobe's environment under your contract, and its retention and extension terms govern how long history remains available. Before you plan exports, read your agreement for the data retention period, the deletion process and any cross-border processing clauses. Your legal team should confirm these terms in the contract itself, not in marketing material.
Consent under CNIL audience measurement rules
CNIL's exemption for analytics trackers is limited to audience measurement and A/B testing, and it does not extend to features such as User ID, heatmaps or session recordings. Session replay and identified product analytics on PostHog therefore need a consent flow, unless your own review finds otherwise. Ask your legal counsel to map each PostHog feature you enable to a consent decision and to confirm the tracker lifetime and IP truncation settings.
EU-US Data Privacy Framework transfers
The European Commission adopted its adequacy decision for the EU-US Data Privacy Framework on July 10, 2023, which allows personal data to flow from the EU to US companies that participate in the framework. Check whether your PostHog Cloud contracting entity participates, and record the transfer basis in your records of processing. Confirm the status with your legal team, since participation and adequacy rules can change.
Identity and SSO on PostHog Cloud
On PostHog Cloud, SSO, audit logs, custom roles and project permissions are sold as platform packages rather than included in every plan. Access controls for analysts, marketers and engineers therefore depend on the package you buy. Confirm which access controls your security team requires, and whether they must be enforced through your existing identity provider before you commit to a cloud plan.
What self-hosting PostHog does not include
Self-hosting PostHog leaves support with your own team. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. The free hobby deployment is a Docker Compose stack installed with a deploy-hobby script under the MIT license, and PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Confirm that the sizing still holds for your expected event volume before you commit to a host, and confirm which upgrade path your engineers will follow. The self-host documentation also notes that new Kubernetes deployments of the paid self-hosted product are no longer supported, so a platform team that standardized on Kubernetes should check that choice before design starts.
The license boundary is the second limit. The repository is MIT licensed except for the ee/ directory, and premium features taken from that directory on a self-hosted instance require a PostHog license. If your Adobe Analytics replacement depends on a premium feature, get the license terms in writing and record which features they cover. If you need fully free software, the posthog-foss repository is purged of proprietary code and features, which means some capabilities you used in evaluation may not be present. Map each required feature to its license tier before you present a cost comparison to finance.
Scale is the third limit. The README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. Adobe customers often run far larger hit volumes, so the practical question is which events count toward that threshold and whether your team will own the capacity planning, backups, upgrades and incident response that Cloud would otherwise handle. Your implementation partner can scope those operational duties in writing, but the accountable owner inside your organization must still be named. Decide that owner before the pilot, not after the first outage.
What a move from Adobe Analytics involves
The sequence turns Adobe's report-driven setup into a documented event schema, a verified PostHog project, and a cut-over that keeps funnels and retention comparable across the switch.
Inventory Adobe reports, feeds and dependencies
The analytics owner and a web developer list every Analysis Workspace report, scheduled export, data feed and alert that people rely on, along with the props, eVars, events and segments behind each one. They also note which Adobe Experience Cloud products consume the data, since those links decide what must be replaced at the same time. The step is done when each report has a named owner, a business question it answers and a decision on whether PostHog will replace it, rebuild it or retire it.
Define the PostHog event schema
Analysts and engineers translate Adobe's props and eVars into PostHog events and properties, rather than copying the Adobe variable numbering. They agree on event names, user identification rules, consent handling and which properties are person properties. Privacy review happens here as well, including whether any tracking will fall outside what a consent exemption would cover. The step closes with a written schema document that the development team signs off on.
Export historical data before retention ends
The team pulls raw history out of Adobe through its data feeds and any historical export Adobe offers, storing the files in the organization's own cloud or data center storage. Because PostHog's managed migrations import historical events directly only from Mixpanel and Amplitude, the Adobe history usually needs a scripted import from files the team controls. Confirm with Adobe the current export options and the retention deadline on your contract, then keep a checksum and row count for each file so the import can be verified later.
Stand up PostHog and import history
Platform engineers deploy either self-hosted PostHog or PostHog Cloud in the region that matches the data residency decision, using PostHog's self-host documentation for the chosen topology. If history is imported, the team confirms that the import path needs a paid product analytics plan and that imports must be sent with the historical_migration flag so they are free of ingestion fees. Imported events cannot be selectively deleted, so the import is tested on a sample first. The step is done when a test import reconciles against the exported files.
Reimplement tags through a tag manager
Front-end developers replace the Adobe Analytics tags with PostHog snippets or SDK calls, delivered through the existing tag manager so that releases do not require code changes in every template. Each event in the schema is tested in a staging environment and the captured properties are checked against the documented names. Consent banners and any session replay settings are configured here, since those choices determine what gets recorded. The step is done when a test checklist passes in every environment.
Run Adobe and PostHog in parallel
For a period agreed in the project plan, both tracking setups run together so the team can compare page and event counts for the same traffic. Differences are logged with a suspected cause, such as bot filtering, duplicate firing or identity stitching, and each is either fixed or accepted with a written reason. Expect some differences because the two products define sessions and users differently. The step is done when the variance is explained for every key metric.
Validate funnels and retention in PostHog
Analysts rebuild the critical funnels, retention views and segments in PostHog and compare them against the Adobe reports from the parallel period. Because imported history is only as good as the events captured in the export, the team also notes where pre-migration retention cannot be compared directly. Stakeholders sign off on each report they depend on, and the sign-off list becomes the acceptance record. The step is done when every report on the inventory has an approved PostHog equivalent or a documented gap.
Cut over and retire Adobe tracking
The team switches production tags to PostHog only, removes the Adobe tags, and confirms that scheduled data feeds and dashboards pointing to Adobe have stopped or been moved. Access to Adobe is reviewed and the exported archive is stored under the organization's retention policy. Ongoing ownership of PostHog, including upgrades and operational support, is assigned to a named team, since PostHog does not offer customer support for self-hosted instances. The step is done when no Adobe tags remain in production and the archive location and owner are recorded.
What drives the cost of each option
The Adobe Analytics side of the cost is set by the contract, not by a public price list, so the first task is to pull your current order form and read the terms that govern volume, data retention and any extension of raw data access. Ask Adobe in writing what happens to report suite history when the contract ends, what a retention extension costs and for how long it runs. Those are recurring commitments that keep growing as traffic grows. On the PostHog side, the pricing page sets a free tier of the first 1 million analytics events each month, with 1 project and 1-year data retention on the Free plan, and 6 projects and 7-year retention on Pay-as-you-go. Compare those limits against your event volume, not your pageview volume, because product analytics counts events per user action.
Self-hosting moves the cost from a subscription to labor and infrastructure. The PostHog self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment, and the README says open-source deployments should scale to about 100k events per month before you move to PostHog Cloud. Above that, you pay in engineering hours for scaling and database operations. Licensing is a separate line: the ee directory needs a PostHog license for premium features on self-hosted instances, so ask the vendor which features your team actually needs and whether they sit in ee or in the MIT-licensed posthog-foss repository. Also budget for the internal analyst time to rebuild dashboards, funnels and event schemas, and for ongoing upgrades and on-call support, which PostHog does not provide for self-hosted instances.
Ask any implementation partner for a fixed-scope quote that separates one-time work from recurring work. One-time items include event schema design, SDK instrumentation, the historical import path (a managed migration from Amplitude or Mixpanel, or a scripted import from a warehouse export), validation of imported counts and cutover. Recurring items include hosting, storage growth, backups, version upgrades, security patching, monitoring and incident response. Ask how much history is in scope, because managed direct imports run at most one year per job and events are not deduplicated, and ask whether the historical import will be paid for separately, since PostHog documents that a paid product analytics plan is required to unlock import features. Finally, confirm in writing who answers when the system fails at 2 a.m., because that answer determines the true cost of the self-hosted option.
Questions buyers ask before switching from Adobe Analytics
Can PostHog replace Adobe Analytics reporting?
PostHog covers many product analytics needs, but it does not map one-to-one onto Adobe Analytics reporting. Its product model is built around events, funnels, session replay, feature flags and experiments, which suits teams whose Adobe use has shifted toward product questions. Adobe's props, eVars and Analysis Workspace reports will need to be rebuilt as PostHog events, properties, insights and dashboards. Before committing, list your highest-value Adobe reports and test each one in a PostHog trial or a self-hosted proof of concept. Confirm any report type you depend on with PostHog's documentation or your own environment.
How much effort does a self-hosted PostHog migration involve, and what drives it?
Effort depends mostly on how many events, properties and reports you must rebuild, how cleanly your Adobe implementation is documented, and how many tags and SDKs must change. Stable infrastructure is a second driver: PostHog's hobby Docker Compose deployment is documented under the MIT license and installed with a deploy-hobby script, but the README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. Ask any implementation partner for a written scope that covers event taxonomy, tag changes, dashboard rebuilds, testing and cutover before you accept a timeline.
Can we keep our historical Adobe Analytics data?
Historical data can be kept in some form, but not as a direct copy into PostHog's event model. Adobe provides data feeds and Data Warehouse exports, so export the raw history before the retention deadline in your contract. PostHog's managed migrations import historical events directly from Mixpanel and Amplitude, and its documented scripted paths cover Google Analytics through the BigQuery export and Heap through Heap Connect, but none of these is listed as an Adobe Analytics importer. Confirm the replay path with PostHog and your data team. Also note that, per PostHog's migration documentation, there is no way to selectively delete event data once imported, so test imports on a separate project first.
What internal skills does running self-hosted PostHog require?
Your team needs people who can operate Docker, Linux servers, a reverse proxy, backups and upgrades, and at least one person who understands the event schema and SQL-based analysis. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. That means your team, or a partner you contract, owns troubleshooting. The documentation also notes that new Kubernetes deployments of the paid self-hosted product are no longer supported. Confirm the minimum skill set with your own platform team before you start.
Can DeployOpen implement and support self-hosted PostHog for us?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. Because PostHog does not provide vendor support for self-hosted instances, a partner's written support terms become the main support path for your team. DeployOpen does not publish a price list, so request a quote based on your written scope.
Do consent rules apply to PostHog session replay?
Yes, session replay usually needs a consent review, and it falls outside the exemption that regulators describe for simple audience measurement. France's CNIL lists conditions for analytics trackers to be exempt from consent, including limiting purposes to audience measurement and A/B testing, a single publisher scope and a tracker lifetime of at most 13 months. Matomo's ePrivacy FAQ notes that features such as heatmaps or session recordings remove that exemption. Hosting PostHog yourself keeps data under your control, but it does not remove the consent obligation for replay. Have your privacy counsel confirm the configuration, masking and retention settings for your sites.
How DeployOpen helps teams evaluate and move
Moving from Adobe Analytics to self-hosted PostHog changes the data model, not just the tag. The four services below follow the same path: map the event model first, implement and harden PostHog inside your own infrastructure, seed history only where the data allows it, then keep the stack patched. DeployOpen does not publish prices, and a quote follows from a written scope.
Event model and data mapping
Start by mapping Adobe props, eVars, events and classifications to PostHog events, properties and person properties. Decide which Adobe variables become identified users, which become group properties, and which can be dropped. Review how session and visitor identity carry over, since PostHog's funnels and retention depend on a consistent distinct ID. The output is a written tracking plan that your analysts and developers sign off before any SDK changes. Confirm the event naming and property schema with your analysts before implementation starts.
Self-hosted PostHog implementation
Scope the deployment inside your own cloud account, data center or air-gapped network. The free Docker Compose hobby deployment is MIT licensed and suited to evaluation, but it is not a production design for high event volumes. Separate the MIT core from the ee directory, decide whether you need premium features under a PostHog license, and document the decision. Hardening covers network exposure, secrets, TLS, access control and backups. Ask for a sizing review against your expected event volume before committing hardware.
History seeding under written scope
Adobe history can only be seeded from what Adobe lets you export. Map which raw data feeds you hold, how they will be transformed into PostHog events, and what the target import path is. PostHog's managed migrations cover Mixpanel and Amplitude, not Adobe, so a scripted import is the usual route. Agree in writing what history is seeded, which reports will not be recreated, and how duplicates will be handled, because imported events are not deduplicated. Confirm the export window against your Adobe retention terms.
Support, upgrades and retainer
PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product or infrastructure questions on self-hosted instances. A DeployOpen retainer can cover monitoring, version upgrades, backups, patch windows and documented runbooks for your team. Scope what is covered, response expectations, and who owns the event schema after handover. Ask whether upgrades will follow PostHog releases or a schedule you approve. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies do that work, and DeployOpen prepares the controls and evidence they review.
