How to use this product analytics requirements checklist
A product or digital team that needs event tracking, funnels and session replays kept in its own infrastructure usually ends up comparing PostHog, OpenReplay and Umami at the same time. The fastest way to waste a month is to start with the feature grid. The first decision is the edition, because these platforms are licensed differently and supported differently. PostHog's repository is under the MIT Expat license except for the ee/ directory, which carries a separate license, and its README says premium features from that directory need a PostHog license on a self-hosted instance. OpenReplay's monorepo is mostly AGPLv3, some directories are MIT, and everything under ee/ is under a commercial license. Umami is MIT licensed throughout its published project. Confirm which code paths your team would actually run before you score any feature.
The checklist that follows is organized by requirement type: functional must-haves, hosting and data residency, identity and access, privacy and retention, integrations, and operations and support. Each item carries a verification step, meaning a check you can run in a test instance or a question you put to the vendor in writing. Many requirements only separate the platforms once the edition, license and support model are known. For example, SSO, SCIM, audit trails and custom roles are described in published materials as paid or enterprise-tier features on some platforms, so a checkmark next to them means little until you confirm which edition includes it. PostHog's self-host documentation also states that self-hosted deployments are officially unsupported, which changes how you should score operations and support.
Work through the sections in order and record the edition, license obligations and support terms for each candidate before you score features. Mark any item that a supplied fact or vendor document does not confirm as an open question, and assign an owner to it. Scores recorded this way hold up in procurement and in a security review, and they show which gaps need an implementation partner, an internal engineer or a paid tier. The sections below give you the requirements to test, not a recommendation for one platform.
Functional must-haves for product analytics and session replay
This table lists the functional capabilities a self-hosted product analytics and session replay platform should cover, why each matters, and how to verify it. Use it as a shortlist filter, then confirm each row in the edition you plan to run, because the same product can split features between free and paid tiers.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Event capture on web | Every funnel, retention and replay analysis depends on reliable events from the browser, including first-party collection from your own domain. | Run a proof of concept on your staging site and compare captured events against your tracking plan. Confirm the SDK documentation for your framework. |
| Event capture on mobile | Native iOS, Android and React Native apps often need separate SDKs, offline buffering and app store privacy disclosures. | Check whether the platform lists native mobile SDKs for your stack, then test offline event queuing on a device with network loss. |
| Funnels and conversion paths | Product teams need step-by-step conversion analysis to find where users drop off in onboarding, checkout or account setup. | Build a three-step funnel on test traffic in each candidate. OpenReplay lists funnels, and PostHog lists product analytics; confirm both in your edition. |
| Retention and trends | Retention shows whether features keep users, and trend charts show movement over time. Both are needed for regular product reviews. | Compare a cohort retention chart against a known sample dataset. Confirm the retention view is included in the edition you are evaluating. |
| Heatmaps and user journeys | Click and scroll patterns and path analysis help teams find confusing interface elements that funnels alone do not reveal. | Confirm heatmaps and journey views are in the product, not only in a managed tier. OpenReplay lists heatmaps and journeys in its README; verify the same in your build. |
| Session replay with console and network data | Replays are most useful when paired with console errors, JavaScript exceptions and network requests that explain a failed step. | Reproduce a known JavaScript error and a failed API call in test, then confirm both appear alongside the replay timeline. |
| Feature flags and experiments | Teams often want to tie a release or A/B test to the same analytics data, which avoids a second tool and a second data copy. | Confirm which flags and experiments require a paid license or a separate module. PostHog lists experiments and feature flags among its products; check their status in your edition. |
| Cookieless or consent-light tracking | Some teams need analytics without cookies or without identifying users, which changes consent and records-of-processing work. | Umami describes itself as cookieless and without automatic personal data collection. Confirm the same behavior in the platform and SDK you choose, then document it. |
| Historical data import | Migrating from an existing tool keeps trend history intact, but import limits and paid-plan requirements can change the migration plan. | Ask the vendor for import limits, supported sources and whether imported events can be deleted later. Test a small import before committing to a migration date. |
Which edition and license obligations fit your requirements
Start by deciding which edition your requirements need, because the three candidates do not license the same way. The PostHog repository is MIT licensed except for the ee/ directory, which sits under its own license. The README states that using premium features from that directory on a self-hosted instance requires a PostHog license, so any requirement for SSO, audit logs, custom roles or project permissions moves you into a licensed edition. PostHog's pricing page also lists those controls as platform packages. OpenReplay is different: most of its monorepo is AGPLv3, some directories are MIT, and everything under ee/ falls under a separate commercial license. Umami is MIT licensed throughout its published repository. Write down each requirement that depends on an enterprise control, then match it to the edition that includes it before comparing prices.
Take the license questions to legal before the build starts. Ask whether the organization is comfortable running PostHog's premium ee/ features under a PostHog license, and whether that license terms fit your audit and procurement rules. For OpenReplay, ask what the AGPLv3 obligations mean if you modify the code and make it available to users over a network, since that is where AGPL terms usually differ from permissive licenses. Your counsel should also confirm which directories you will run and whether any MIT-licensed parts are combined with AGPL code in your own build. Ask whether a fully free route such as the posthog-foss repository, which the PostHog README describes as purged of proprietary code and features, is acceptable, and what it gives up in feature coverage and upgrade path. Those answers decide which requirements remain on the checklist.
Hosting and data residency requirements to write down
Hosting decisions set the boundary for everything else on the checklist. Before comparing features, write down where event and replay data must physically reside, which deployment targets your platform team can run, and whether a managed or bring-your-own-cloud option satisfies your residency rules. The cards below cover the items to record and the vendor facts to check against them.
Physical location of data
Decide whether event and replay data must stay in your own cloud account, a specific data center, or an air-gapped network. Each option changes who can reach the database, the object storage holding recordings, and the backups. Write the boundary as a statement that auditors and data protection reviewers can test, including any region or country limits. Confirm with each vendor which components, such as caches, queues and support tooling, touch customer data and where they run.
Supported deployment targets
List the environments your team already operates and check each platform against them. OpenReplay's README names AWS, Google Cloud, Azure, DigitalOcean, Scaleway, OVHcloud, Kubernetes with Helm, Docker and Ubuntu as deployment targets. Your list may include private clouds or hardware that a vendor does not document. Ask for the supported operating systems, database versions and storage classes, and confirm them in writing before the proof of concept.
Minimum server sizing
Record the minimum sizing each vendor publishes, then plan above it for your traffic. PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its free hobby deployment. OpenReplay says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start. Treat these as starting points for a test environment, not production capacity, and ask the vendor how sizing changes with event volume and replay retention.
Docker Compose or Kubernetes
Choose the orchestration model before the design review. Docker Compose suits a single host for evaluation or small internal use, while Kubernetes with Helm suits teams that already run clusters, need rolling upgrades and want per-component scaling. PostHog no longer supports new Kubernetes deployments of its paid self-hosted product, so confirm which model applies to the edition you need. Ask who maintains the chart or compose file after go-live, and how upgrades are tested.
First-party tracking from your domain
Decide whether the tracking script loads from your own domain or a third-party host. OpenReplay's README states that first-party tracking from the operator's domain is not blocked by ad blockers, which affects how complete your event and replay data will be. Record which domain or subdomain the script uses, who controls its TLS certificate, and how the script is versioned. Check that the setup does not route visitor data to any third-party host without a documented reason.
Managed and bring-your-own-cloud options
Test each managed option against your residency statement before you accept it. OpenReplay lists Serverless, Dedicated and Bring-Your-Own-Cloud options on AWS, GCP or Azure, while PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions. A managed service may still place support access, backups or subprocessors outside the required boundary. Ask for the region list, subprocessor list, support access model and the location of backups for each option you consider.
Identity and access requirements by team and role
Engineering and product teams install SDKs, define event tracking plans, build dashboards and manage feature flags or experiments in the same tool. They usually need the widest project access, but that breadth should still be tied to the company identity provider so that offboarding removes access everywhere at once. Confirm early whether your chosen edition supports SSO through SAML or OpenID Connect, and whether SCIM provisioning creates and removes users automatically from your directory.
- SSO and SAML: Log in through your corporate identity provider, with multi-factor authentication enforced there rather than in the analytics tool.
- SCIM provisioning: Create, update and deactivate accounts from the directory so that leavers lose access without a manual ticket.
- Project permissions: Grant access per project or environment, separating production event data from staging or test projects.
- Audit trails: Record who changed tracking settings, retention, masking rules or user roles, so configuration changes can be reviewed.
- Least privilege for replays: Keep replay viewing off by default for engineers who only need aggregate funnels or error data.
Before committing, confirm which of these features your edition includes. PostHog sells SSO, audit logs, custom roles and project permissions as platform packages, and OpenReplay's self-hosted Enterprise edition lists SSO and SAML, SCIM provisioning, roles and permissions, and audit trail. Confirm each item in the edition you will actually run.
Analysts query funnels, retention and cohorts, and often export data to other tools. Their access is mostly read-only, but exports and saved queries can move personal data outside the analytics stack, so their permissions need to be scoped as carefully as engineering access. The key requirement is separating what an analyst can see from what they can download or share.
- Role-based access: Use a read-only or analyst role that can view dashboards and insights but cannot change tracking configuration or retention.
- Scoped projects: Limit analysts to the products, sites or apps they cover, especially when several brands share one instance.
- Export controls: Confirm whether the edition lets you restrict CSV exports or API keys for individual users, and who approves them.
- Personal API keys: Require that keys are tied to a named user and revoked when that user leaves, so access does not outlive the employee.
- Audit of exports and queries: Confirm whether query or export activity is logged, since this is the evidence most reviewers ask for.
Ask the vendor or partner to demonstrate a read-only role exporting data, and check whether the export is logged. Many self-hosted setups rely on the edition's role model, so confirm role names and permissions in your own environment rather than assuming they match the labels in documentation.
Support staff often open session replays to reproduce a customer problem, which makes replay access the highest-risk permission in the stack. A recording can show form contents, account pages or messages if masking was incomplete. Access should be granted per case, time-limited where possible, and recorded, rather than given to every support agent by default.
- Replay-only role: Create a role that can watch replays for named sessions but cannot edit masking rules, retention or user management.
- Just-in-time access: Grant replay access for a specific ticket or period, then remove it, using a documented approval step.
- Masking dependency: Confirm that replays are masked at capture, so support views do not depend on staff remembering to hide data.
- Audit of replay views: Confirm whether the edition records who opened which recording and when, since this is what a privacy review will ask for.
- Session identification: Restrict search by user identifier, so agents cannot browse all recordings for a given customer without a reason.
Illustratively, a support agent who needs one recording should not gain the ability to browse the full library. Confirm with the vendor whether replay view logging and per-session restrictions exist in your edition, and test them with a non-production account before rollout.
Agencies that build tracking plans or run campaigns, and auditors who review controls, need access without ownership of the platform. External accounts should be separate from employee accounts, limited to the projects they need, and expire on a fixed date. Auditors usually need evidence about access rather than live access to recordings, so the access model should let you produce reports instead of granting direct viewing.
- Separate external accounts: Keep agency and auditor identities distinct from workforce identities, with their own review cycle.
- Time-bound access: Set an end date for each external account, and confirm whether the edition supports expiry or whether you must remove it manually.
- No replay access by default: Give auditors reports on role assignments, masking configuration and retention settings, not recordings of end users.
- Evidence exports: Confirm whether user lists, role assignments and audit logs can be exported for a review.
- Access reviews: Schedule periodic reviews of external and privileged accounts, and record the outcome.
Confirm with your implementation partner who will hold administrator rights during the engagement and how those rights are removed at handover. This should be written into the fixed scope, along with the list of accounts and their expiry dates.
Privacy, consent and retention requirements
Write down a retention period for each data type before you compare platforms: event data, session recordings, and any identifiers attached to them are three separate decisions. Event retention and recording retention often differ, because recordings carry far more sensitive content than aggregated events. Check what each candidate lets you set per project or per data type, and whether a deletion job can run on a schedule or only by hand. Hosted tiers publish retention by plan, so when you self-host, the retention setting is yours to configure and to evidence. Confirm the exact retention controls in each platform's current documentation rather than assuming parity.
Decide early whether tracking must be identified or anonymous. Anonymous tracking reduces the number of requests you must answer, but it limits funnels tied to accounts. Umami is designed to work without cookies and without automatic collection of personal data, which simplifies consent in many cases, though your own event properties can still carry personal data. Session replay and identified analytics are the areas where consent in the EU and similar regimes most often applies, so gate the SDKs behind your consent tool and confirm the platform's behavior when consent is withheld. Deletion and access requests also need a documented path: ask each vendor how a single user's events and recordings are located and removed.
Plan erasure around what cannot be undone. PostHog's managed migration documentation says events imported from Mixpanel or Amplitude cannot be selectively deleted once imported, so a migration that brings in personal data creates an erasure problem you must solve before the import, not after. Filter or minimize data at the source, and keep a record of what was loaded and when. For depth on consent gating and recording masking, see the self-hosted web analytics hub for consent-free setups, and treat the consent and masking topics in this group as the detailed follow-up. Record each answer in your records of processing so auditors and data protection reviewers can trace the decision.
Integration requirements to test before go-live
How do I install a self-hosted product analytics tag through a tag manager or CMS?
Install the tracking snippet or SDK through your tag manager or CMS template only after you confirm the script loads from your own domain and respects your consent setting. Test the install on staging before production, because a tag that loads before consent is recorded creates a compliance gap. Confirm with each platform whether it supports first-party hosting of its script and whether your CMS can gate it behind a consent tool. Check how the tag behaves on single-page route changes, since page views and events can be double counted or missed. Document the exact snippet version and the place it is inserted so that front-end releases do not silently remove it. For OpenReplay, the README notes that first-party tracking from your own domain is not blocked by ad blockers, which is worth verifying in your own environment.
Can self-hosted product analytics export events to our data warehouse?
Confirm the export path for each candidate before you commit, because the answer depends on the platform version and your deployment, not on the marketing page. Ask the vendor or check the documentation for a supported export or streaming option, the format of exported events, and whether exports include session metadata and user identifiers. Test a full export against a sample of production-like data and reconcile row counts with the source. Agree who owns the pipeline, who pays for the warehouse storage and compute, and how schema changes are versioned. If your architecture is warehouse-first, you may prefer an open-source pipeline that writes events directly to your warehouse, which is a separate design choice covered on its own page.
How do feature flags and experiments connect to product analytics?
Feature flags and experiments need a shared user or session identifier so that exposure and outcome events can be joined reliably. Confirm whether your chosen analytics platform includes flags and experiments or whether you will run them on a separate tool, since PostHog's README lists feature flags and experiments within its product range while other candidates may not. Test that a flag change is recorded as an event, that variant assignment is stable across sessions, and that users are not exposed to both variants. Decide which system is the source of truth for experiment results, and document how sample ratio mismatches will be detected. Check licensing for any paid feature in the flag or experiment module before you rely on it.
What do mobile SDKs for iOS, Android and React Native need to work?
Mobile analytics needs SDKs that match each platform and a plan for offline buffering, app store privacy disclosures and identifiers. Confirm that each candidate publishes SDKs for iOS, Android and React Native, and check their current versions and minimum OS support in the vendor documentation. OpenReplay's README lists native mobile replay for these platforms, but verify the replay masking behavior on each device type before you go live. Test event delivery when the device is offline and when the app is closed, and confirm how events are sent after reconnection. Update your app store privacy labels to match what the SDK actually collects. Agree who maintains the SDK upgrades in each release cycle.
Can we migrate historical data from Mixpanel, Amplitude, Google Analytics or Heap?
Historical migration is possible for some sources, but the limits are specific and should be tested before you promise stakeholders a full history. PostHog's managed migrations import events directly from Mixpanel or Amplitude using API credentials, or from JSONL files in an S3 bucket. Each direct import job covers at most one year of data, events are not deduplicated, and there is no way to selectively delete event data once imported. Historical imports sent with the historical_migration flag avoid ingestion fees, but a paid product analytics plan is required to unlock the import features, according to PostHog's documentation. Plan for duplicate removal before the import, run a pilot on one month of data, and reconcile totals against the source. Migration guides exist for Google Analytics and Heap, so confirm which of these paths applies to your data and your plan. Ask the vendor to confirm the current limits in writing.
How do we connect product analytics alerts to our observability stack?
Connect analytics alerts to your observability stack only after you define which signals matter, such as event drop-offs after a release, ingestion failures or replay storage nearing a limit. Confirm whether each platform exposes health metrics, webhooks or an API that your monitoring tool can read, and check the authentication model for those endpoints. Route alerts to the team that owns the release, not a shared inbox, and test them with a deliberate failure in staging. Track the health of the analytics platform itself, including its database and storage, because a silent ingestion failure is the most common way teams lose data. Ask whether the vendor supports the monitoring integrations you already use, and budget for the operational work of keeping those links current.
What should we ask an implementation partner about integration testing?
Ask the partner to put each integration into the written scope with a named test, an owner and an acceptance condition. A fixed-scope engagement works best when the integration list, the sample data, the test environments and the handover documentation are agreed before work starts. Ask how the partner will verify tag installs, warehouse reconciliation, flag exposure, mobile offline behavior and migration totals, and whether those tests run again after each platform upgrade. DeployOpen implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can scope integration testing as part of a written engagement. Ask what is excluded, such as third-party SDK changes or source system fixes, and how changes after go-live are priced.
Operational requirements and how to verify them
This table compares the operational requirements that self-hosted analytics demands, from upgrades and backups to support, and gives a verification step for each. Read it as a checklist to put to each candidate platform and to your own platform team before any selection. The main takeaway is that PostHog's self-hosted deployments are officially unsupported, so the operating burden for any self-hosted option sits with your team or your implementation partner.
| Requirement | What to ask for or confirm | How to verify it before choosing |
|---|---|---|
| Upgrade cadence and release tracking | A published release history and a named upgrade path. Umami v3.4.0 was published on September 17, 2026, and OpenReplay v1.28 on September 25, 2025, per their release pages. | Rehearse an upgrade on a staging copy with production-like data and record the steps, downtime and rollback path. |
| Backup and restore | Documented backup of the database and any object storage holding replays, with a stated restore procedure from the vendor or your partner. | Run a full restore into a clean environment and confirm analytics, funnels and replays are readable afterward. |
| Storage growth and retention planning | Expected storage per event and per replay minute, plus how retention is enforced. OpenReplay's README suggests 50 GB as a starting point for a small single VM. | Load a representative event sample, measure growth over several days and confirm deletion jobs actually remove expired data. |
| Monitoring and alerting | Health metrics for ingestion, query latency, queue depth, disk use and replay processing, with alerts routed to on-call staff. | Simulate an ingestion stall and confirm an alert fires and reaches the responder within your target. |
| Uptime targets | A target you set internally, and whether the platform's design supports redundancy across zones or nodes. Vendor SLAs apply only to paid managed or enterprise tiers. | Ask for the vendor's written SLA for each edition, and test failover of your own deployment before relying on it. |
| Support model | Whether vendor support covers your self-hosted install. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer product or infrastructure support for them. | Get in writing who answers a production incident, on what hours, and whether a retainer with an implementation partner covers upgrades and fixes. |
| Security patch cadence | A stated process for security fixes and the versions that receive them, including any edition-specific gaps. | Track the patch timeline against your change calendar and confirm who applies and tests each patch. |
| Documentation and runbooks | Install, configuration, backup and incident runbooks that your team can follow without the original builder. | Have an engineer who did not perform the install follow the runbook in a test environment. |
Event volume and scale checks that change the platform choice
Measure your expected monthly event volume and session replay volume before you compare platforms, because scale decides which self-hosted options remain practical. The PostHog README states that open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that level. Treat that figure as the vendor's own guidance, not a hard limit, and confirm it against the current README and the self-host documentation before you rely on it. Count events per month across web and mobile, include repeat sessions and autocapture if you plan to use it, and separate replay volume from event volume because recordings consume storage on a different curve.
Compare the volume tiers that each vendor publishes, since they show how the commercial model treats growth. Umami Cloud lists Hobby at up to 100K events with 6 months of retention, Pro at 1 million events with 2 years of retention, and Business at 10 million events with 5 years of retention, so retention and volume are priced together. PostHog's pricing page lists a free monthly allowance of 1 million analytics events, with retention set by plan. Use these figures to see where your expected volume and retention need would sit on each vendor's own ladder, and confirm current numbers on the pricing pages because they change.
Ask each vendor, in writing, how sizing and storage grow with volume. Request the recommended server size at your target volume, the database and storage growth per million events, how retention settings change disk use, and what happens to replay storage at peak traffic. Then set a decision point: if your projected volume or retention approaches the vendor's stated limits within your planning horizon, decide now whether you need a warehouse-based design that moves events into your own analytical store, or a managed service for the analytics layer. Record that decision and its trigger in the requirements so the platform choice does not lock you into a design you will outgrow.
How to run the evaluation in a sequence
This sequence moves a team from a shortlist of self-hosted options to a fixed scope they can take to procurement, with each step producing a document that the next step depends on. Legal, security, product and operations each own a piece, so the decision rests on evidence rather than on a demo.
Confirm licensing and edition fit with legal
Legal and the platform owner review the license of each candidate and the edition that contains the features you need. For PostHog, the MIT-licensed core is separate from the ee/ directory, which requires a PostHog license for premium features on a self-hosted instance. OpenReplay follows a similar split, with the ee/ directory under a commercial license. Legal should also confirm whether the free build covers SSO, audit logs and role-based access, since those may sit in paid tiers. The output is a licence register listing each component, its license, and the edition that unlocks each required feature. The step is done when legal signs off on that register.
Write retention and residency rules
The privacy lead, data protection officer and product owner agree how long events and recordings are kept, which regions they may be stored in, and who can request erasure. Write these as numbered rules, not preferences, so each candidate can be tested against them. Confirm the hosting location of any managed option you still consider, and note that self-hosting keeps session data in your infrastructure only if your own deployment and CDN settings do too. The output is a one-page data rules document. The step is done when the rules have an owner and a review date agreed in writing.
Score functional must-haves
The product team turns the required capabilities into a scored matrix, covering event tracking, funnels, retention, session replay, DevTools data, feature adoption views and mobile support if needed. Each candidate receives a score against each row, with evidence taken from its documentation or a test install, not from marketing pages. Mark any capability you could not confirm as unverified and assign it to the proof of concept. The output is a weighted scoring sheet with a short evidence note per cell. The step is done when every must-have has a score and a named verifier.
Run a proof of concept on a staging site
The engineering team installs the shortlisted platforms on a staging environment that mirrors your production front end, then instruments a test set of pages and forms. The security team tests capture-time masking by inserting dummy card numbers, balances and personal identifiers into fields, and checks that they are absent from stored events, recordings and network payloads. Repeat the masking test after a front-end release, because a changed selector can silently expose data. The output is a proof-of-concept report with masking test results and a list of gaps. The step is done when every masking case passes or has a documented fix.
Check migration of existing data
Analytics lead and engineering confirm whether historical data must move from an existing tool, and what that tool can export. For example, PostHog's managed migrations import from Mixpanel or Amplitude through API credentials or JSONL files in S3, each direct import job covers at most one year of data, events are not deduplicated, and there is no way to selectively delete imported event data. Decide whether a clean start with a parallel run is acceptable. The output is a migration decision record with sample exports and a dedupe plan. The step is done when the business accepts the historical gap or the migration path is tested.
Review operations and support terms
The platform owner and procurement review who runs the stack after go-live, including upgrades, backups, monitoring, incident response and capacity planning. Check each candidate's support model in writing. PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for self-hosted instances, while OpenReplay's free edition offers community support. Ask what the paid tier's support and SLA cover. The output is an operations responsibility matrix showing what your team, a partner and the vendor own. The step is done when every operational task has a named owner.
Write a fixed scope before procurement
The project lead combines the outputs of the previous steps into a written scope that states the platform and edition, hosting environment, integrations, masking rules, migration boundaries, retention settings, support model and acceptance tests. Share the draft with any implementation partner you are considering, and ask them to confirm each deliverable and exclusion in writing. The output is a fixed-scope statement that procurement can price and compare. The step is done when security, legal and operations have each signed the scope, and it is ready for a quote.
Questions buyers ask before choosing a self-hosted platform
How much effort does a self-hosted product analytics evaluation take?
The effort depends on how many platforms you compare, how many systems the tool must touch, and how much of your traffic you test against. A fair evaluation runs each shortlisted option through the same event plan, the same masking rules and the same hosting target, so the results are comparable. Plan time for four areas: confirming licence terms for the edition you would actually run, deploying a test instance in a non-production environment, checking that session replay masking holds on your real pages, and reviewing the data flows with security and privacy staff. Edition fit is the first thing to settle. PostHog's README separates MIT-licensed code from the enterprise directory, and OpenReplay's README describes a separate commercial licence for its enterprise directory, so an evaluation that ignores edition differences will mislead you about features and obligations.
Can our team run a self-hosted analytics platform without outside help?
Some teams can, but only if they already operate containers, databases and certificates reliably and can own upgrades. Community deployments are a workable starting point: PostHog's self-host documentation describes a free Docker Compose hobby deployment, and OpenReplay's README says a single virtual machine is enough to start. The gap appears later. Event volume grows, storage and retention need planning, upgrades must be tested against your tracking code, and someone must respond when replays stop recording after a front-end release. PostHog's documentation states that self-hosted deployments are officially unsupported and that it does not provide customer support for infrastructure questions on them. Decide early which parts your staff will own and which you will hand to a partner under a written, fixed scope.
What support is available on community editions?
On community editions, support is usually limited to public documentation, community forums and the vendor's issue tracker. Confirm this against the specific product and version you plan to run. PostHog's self-host documentation says it does not offer customer support for self-hosted instances. OpenReplay's pricing page describes its open-source edition as self-hosted with community support and self-managed retention, and places a custom SLA and dedicated support in its self-hosted Enterprise edition, priced on multi-year contracts. Umami's pricing page states that the open-source version can be self-hosted for free, while its managed cloud tiers add features the self-hosted version lacks. Whatever you choose, ask who answers a production incident, within what process, and whether that commitment is written into the contract.
How long do migration and go-live take for self-hosted analytics?
The timeline is set by scope, not by the tool alone. The main drivers are the number of products and apps being instrumented, whether an existing tool's history must be migrated, how many event definitions need rework, how much masking and consent logic must be verified, and how many environments and approval gates your change process requires. Historical migration has its own constraints. PostHog's managed migration documentation says a direct import covers at most one year of data per job, events are not deduplicated, and once imported, event data cannot be selectively deleted. Those limits affect what you plan to move. Ask any implementation partner for a written schedule tied to a defined scope, and ask which milestones depend on your staff, such as security sign-off or release windows.
What do self-hosted analytics platforms need from our internal staff?
Expect demand on three groups: infrastructure, security and front-end delivery. Infrastructure staff own the hosting target, sizing, backups, patching and monitoring. PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment, and it warns that open-source deployments should be expected to suit about 100k events per month, so sizing will change as usage grows. Security staff review data flows, access roles, retention settings and the masking configuration. Front-end teams must test that capture-time masking still holds after releases, because a new form field or page template can expose data that the previous build hid. Ask each partner and vendor to list the internal roles, hours per week and decision points they expect from your side, in writing.
Does a self-hosted analytics platform meet audit or data protection requirements?
Self-hosting can support these requirements, but it does not satisfy them on its own. Keeping data in your infrastructure helps with residency and third-party transfer questions, and OpenReplay's README notes that self-hosting keeps session data in the operator's own infrastructure. However, the compliance outcome depends on your configuration, your records of processing, your retention settings, your access controls and your consent handling. DeployOpen plans, implements and documents those controls and prepares evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Ask any partner which evidence they will produce, who receives it, and how it maps to the frameworks your auditor will use.
Where should I check the cost and build-versus-partner trade-offs?
Cost depends on who runs the platform, how much event volume you expect, and how much implementation and ongoing support you buy. The licence fee for open-source software is often zero, but infrastructure, staff time, testing and support are real costs that recur. Subscription prices for hosted tiers are published by vendors, such as Umami's Pro plan at $20 per month for 1 million events, and those figures change, so confirm them on the vendor's pricing page before comparing. Our cost and build-versus-partner guidance explains each cost line and what to request in a quote. DeployOpen does not publish a price list; a quote follows from a written scope.
How DeployOpen scopes and delivers a product analytics selection
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For product analytics requirements, we turn your checklist into a written scope that covers which platform options are tested, how they are deployed and what evidence is handed over.
How we scope
- Review your must-have events, funnels, replay needs and identity model against the checklist before naming a platform.
- Confirm hosting location, data residency and retention targets in writing with your security and privacy owners.
- Record in the written scope which platforms, editions and integrations are included, and what is excluded.
How we build
- Deploy the chosen platform in your infrastructure, with capture-time masking and access controls configured to your checklist.
- Test masking, retention and access rules against your own sample pages and flows before any traffic is collected.
- Integrate analytics with your identity provider, logging and data tools as the agreed scope specifies.
How we hand over
- Deliver runbooks for deployment, upgrades, backups, retention settings and access reviews, written for your operators.
- Provide a record of configuration decisions and test results that your auditors or privacy reviewers can examine.
- Confirm acceptance against the written scope, with open items and owners listed for your team to close.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build.
- Plan upgrades for the platform release line you run, and retest masking and access rules after each change.
- Agree in the retainer which events, incidents and reviews are covered, and how your team escalates issues.
