A PostHog implementation can be trusted only for decisions its data lineage can support.

Seeing events in Live Events, a populated funnel, or a revenue chart proves that data reached PostHog. It does not prove that the event means what its name claims, belongs to the correct person, preserves the original acquisition source, represents one real transaction, or uses the same value as the payment system.

A serious PostHog audit tests the entire chain:

Ad -> click -> landing session -> identity -> behavior -> purchase -> realized value -> attribution -> ROAS or another business decision

For a business with meaningful paid acquisition, the strongest practical test is to select a real purchase from the authoritative commerce or payment system and trace it backward through PostHog to the correct person, session, campaign, and useful ad identifier. The audit should then reproduce the same relationship in aggregate and explain the remaining gap.

Not every company needs ad-level ROAS. A content business may need trustworthy anonymous sessions; a product-led SaaS company may need account-level activation and retention; a subscription app may need trial, conversion, renewal, and churn cohorts. The audit standard should match the decision.

The twelve checks below are arranged in dependency order. A later check cannot compensate for an earlier one: a perfect ROAS query is useless if the purchase value is wrong, and a correct purchase event cannot restore an acquisition source lost before identity was established.

What a PostHog audit is—and is not

A PostHog audit is a system-level validation of an existing analytics implementation. It asks whether acquisition, identity, events, properties, revenue, attribution, and queries work together well enough to support defined decisions.

It is not the same as an event tracking plan.

An audit can discover that purchase_completed fires too early, program_started lacks a stable program ID, or plan changes meaning across platforms. It should explain why those defects make the current data unsafe and specify what must be repaired. The detailed method for designing event names, trigger contracts, property schemas, identity keys, and metric definitions belongs in Event Tracking Plan: A Practical Framework for Connecting Traffic, Behavior, and Revenue.

The broader, tool-agnostic principles are covered in Conversion Tracking Audit: How to Know Whether Your Funnel Data Can Be Trusted. This article applies that standard specifically to PostHog.

The PostHog trust standard

A PostHog implementation is decision-ready when it can establish all of the following for the intended use case:

1. The business fact is defined. The team agrees what a purchase, qualified lead, activation, renewal, churn event, or retained account means.
2. The relevant journey is observed. Acquisition and behavior are captured across the domains, apps, checkouts, and backend systems the user actually traverses.
3. Identity is sufficient. The events that must belong to the same visitor, user, account, session, or transaction can be connected reliably enough for the decision.
4. Events are semantically valid. Each event fires at the state transition its name claims and carries the properties needed for analysis.
5. Value reconciles. Purchases, revenue, refunds, renewals, and other business outcomes agree with authoritative systems within an understood and documented tolerance.
6. The query is reproducible. Another analyst can rebuild the metric from documented definitions and obtain the same result.
7. The system stays valid. Releases, retries, consent states, identity changes, schema drift, and pipeline failures are detected rather than silently entering reports.

Trust is not a single property of the PostHog project. It is a conclusion about a specific question.

The 12 PostHog audit checks

Check	What it must prove	Typical decision at risk
1. Decision scope and business truth	The project has explicit questions, entities, definitions, and systems of record.	Every downstream metric
2. Acquisition identifiers at entry	UTMs, platform IDs, and click IDs arrive intact on the first eligible event.	Channel, campaign, and ad reporting
3. Source persistence	Initial, latest, and session-entry source data remain available intentionally.	Attribution and cohort analysis
4. Journey continuity	Sessions and identities survive required domain, app, checkout, and backend transitions.	Funnels and source-to-revenue linkage
5. Identity architecture	Anonymous, known, account, session, and transaction identities are sufficient for the use case.	LTV, retention, personalization, attribution, experiments
6. Event semantics and triggers	Events represent real business or product state changes at the correct moment.	Funnel and behavior analysis
7. Properties and queryability	Required IDs, values, dimensions, types, and context are present and consistent.	Segmentation, revenue, and metric construction
8. Collection and deduplication	Browser, server, webhook, consent, retry, test, and bot behavior do not manufacture or lose facts.	Counts, conversion rate, and revenue
9. Revenue reconciliation	Purchases and lifecycle value match commerce, billing, or backend systems.	Revenue, LTV, and profit reporting
10. Attribution and spend matching	Source rules and ad-cost joins are explicit, reproducible, and appropriately granular.	ROAS and budget allocation
11. Metric and query validation	Key reports use correct entities, filters, windows, denominators, and dates.	Management dashboards and decisions
12. QA, monitoring, and governance	Owners can detect and repair drift after the audit.	Long-term reliability

1. Define what PostHog must be trusted to answer

Begin with decisions, not events.

An audit should list the questions PostHog is expected to support, such as:

• Which acquisition sources produce realized revenue rather than only leads?
• Which ad or campaign has the highest observed ROAS?
• Where do eligible users leave the activation funnel?
• Which product behaviors predict retention?
• Which accounts adopted a feature after being exposed to it?
• How many subscriptions started, renewed, refunded, or churned?
• Did an experiment change the intended business outcome?

Each question needs a defined entity, outcome, time basis, and authoritative reference.

PostHog should not be declared the universal source of truth. Different systems are authoritative for different facts:

Fact	Likely authoritative system
Ad spend and platform delivery	Advertising platform or ingested cost table
Landing behavior and product interaction	PostHog events
Account and entitlement state	Product backend or account database
Payment captured	Payment processor or commerce backend
Refund and chargeback state	Payment processor or finance system
Lead stage and closed sale	CRM or sales system
Experiment assignment and exposure	Experimentation implementation and assignment logs

The audit tests whether PostHog represents and joins these facts correctly. It does not replace the systems that generated them.

This first check also establishes project scope:

• production, staging, and development environments;
• web, mobile, server, ecommerce, CRM, and billing sources;
• project timezone and base currency;
• internal, QA, partner, and bot traffic rules;
• data-retention and consent constraints;
• the decisions that do not require identified users or full attribution.

Pass evidence: a short decision and source-of-record matrix, not a list of existing dashboards.

2. Verify acquisition-source and ad identifiers at the landing event

PostHog cannot attribute a conversion to information that never arrived.

The audit should start from real campaign URLs, not from a UTM spreadsheet alone. For representative Meta, Google, TikTok, Reddit, LinkedIn, email, affiliate, and partner links, inspect the actual click and verify that the final landing URL contains the expected identifiers after every redirect.

At minimum, acquisition data may include:

• utm_source;
• utm_medium;
• utm_campaign;
• utm_term;
• utm_content;
• a stable campaign ID;
• ad set or ad group ID;
• ad or creative ID;
• platform click IDs such as gclid, fbclid, or equivalents;
• affiliate, partner, or referral IDs.

PostHog automatically captures standard UTM parameters when they are present and makes them available on events, as initial and latest person properties, and as session-entry properties. That behavior is useful, but it cannot repair inconsistent naming, stripped query parameters, missing dynamic macros, or the wrong destination URL. See PostHog’s UTM segmentation documentation.

Stable identifiers and human-readable names serve different purposes. Names are readable but can be edited. Platform IDs are better join keys. For ad-level analysis, capture the most granular identifier that is stable and actually available in both the landing data and the ad-cost data. An individual click ID is valuable for diagnostics and platform feedback; an ad ID is usually the more practical grouping key for per-ad reporting.

99ways’ UTM guideline covers taxonomy and link governance. The platform-specific ad URL parameter guide covers dynamic ID templates. The audit should test whether those conventions work in production rather than reproduce them here.

Verify acquisition identifiers survive the full landing path

Test at least:

• direct landing;
• every redirect and link shortener;
• mobile in-app browsers;
• consent accepted, rejected, and delayed;
• deep links and app-store handoffs where relevant;
• links containing encoded characters;
• renamed campaigns and duplicated campaign names.

Pass evidence: raw landing events from clean test journeys containing the expected source and stable IDs, plus a registry showing how each field maps to the advertising platform.

3. Verify source persistence through the session and conversion journey

Capturing UTMs on the first pageview is not the same as preserving attribution to the outcome.

The audit should distinguish three questions:

1. Initial source: What first brought this person into the observed journey?
2. Session-entry source: What brought this browser or device into this session?
3. Latest or converting source: What source preceded the conversion under the chosen attribution rule?

These values should not overwrite one another accidentally.

For each representative journey, verify that source fields remain available after:

• navigation to another page;
• form submission;
• login or signup;
• a return session;
• a redirect to checkout;
• a browser-to-server purchase confirmation;
• an app handoff;
• a CRM or billing event arriving later.

PostHog’s campaign-attribution troubleshooting guide notes that when UTMs appear on pageviews but not conversions, identity fragmentation is often the real problem: the distinct_id that received the landing event is no longer connected to the conversion. See Campaign attribution troubleshooting.

Also test whether internal links introduce new UTMs. UTMs placed on links inside the site can overwrite or fragment the original campaign context and should not be used as an internal navigation taxonomy.

Source persistence must be deliberate. The audit should document:

• which fields are immutable first-touch values;
• which fields update at each new session;
• which fields describe the conversion event itself;
• how anonymous source data becomes attached to a known person or account;
• what happens when consent or storage restrictions prevent persistence.

Pass evidence: the same test journey shows the intended initial, session-entry, and conversion-source fields at each stage, without hidden overwrites.

4. Verify continuity across domains, apps, checkouts, and backend systems

Many PostHog implementations are correct on each page and broken between pages.

Map the complete customer journey and the corresponding data journey. Common transitions include:

• marketing site -> product app;
• marketing site -> Shopify or another hosted store;
• product -> Stripe checkout;
• website -> booking tool;
• website -> native app;
• app -> web subscription flow;
• browser event -> backend confirmation;
• lead form -> CRM;
• purchase -> renewal or refund webhook.

Subdomains can often share first-party PostHog storage. Separate top-level domains require an explicit continuity strategy. PostHog’s cross-domain guidance describes passing and bootstrapping distinct_id and $session_id when the same journey must remain connected across websites. See How to set up cross-domain tracking in PostHog.

Continuity does not always mean forcing every environment into one session. The requirement depends on the decision:

• If the question is whether a landing page led to a purchase on a separate checkout domain, the purchase must join to the originating person and source.
• If the question is anonymous content engagement, a new session on another device may be acceptable.
• If the question is account retention, device-level continuity matters less than stable account identity.

Audit both the visible journey and the technical handoff. A redirect can preserve UTMs while losing the person. A backend purchase can use the correct person but omit the originating session. A CRM event can join by email while creating duplicates when addresses change.

Pass evidence: a transition matrix showing which identifiers cross each boundary, how they are transported, and which analytical questions remain limited when they cannot be preserved.

5. Verify that the identity architecture is sufficient—not maximally complex

Identity is correct when it is sufficient for the business question and stable within the required scope.

The audit should ask:

• What identifies an anonymous visitor today?
• What stable identifier exists after signup, login, lead submission, or purchase?
• When is identify() called?
• Does the same identifier reach the frontend, backend, mobile app, billing events, and CRM?
• What happens when the user logs out or another user shares the device?
• Are account or organization entities modeled separately from people where needed?
• Can one purchase or subscription be joined by a transaction-level ID even if person identity is incomplete?
• What fragmentation is acceptable for the intended analysis?

PostHog explicitly treats identity coordination as an engineering responsibility. It can merge IDs that the implementation supplies, but it cannot infer that independently generated browser, mobile, server, and checkout identifiers represent the same person. Incoherent identity can fragment funnels, attribution, session replay, feature flags, and experiments. See Identity resolution.

A simple site with no accounts may need only reliable session and transaction identifiers. A SaaS product measuring activation and retention needs stable user and account IDs. A paid-acquisition business linking first touch to subscription renewals may need anonymous-to-known continuity, transaction IDs, subscription IDs, and a stable customer or account key.

Define the minimum identity model required for reliable analysis

The audit should look for:

• generic IDs such as null, anonymous, or a shared service account;
• email addresses used as primary IDs when they can change;
• inconsistent casing or formats across SDKs;
• identify() firing after critical conversion events;
• frontend and backend events using different IDs;
• anonymous sessions that never merge;
• logout flows that fail to reset shared-device state;
• accidental merges of distinct people;
• one person representing several business accounts without a group model.

Do not prescribe a global identity graph if the business does not need one. Every additional identity rule adds implementation and privacy complexity. The audit should describe the minimum model required for the decisions in scope.

Pass evidence: person-profile traces for representative anonymous-to-known journeys, plus an identity diagram naming canonical IDs, merge points, reset behavior, and accepted blind spots.

6. Verify that events mean what their names claim

An event is trustworthy only when its trigger corresponds to the state change implied by its name.

A PostHog project can contain millions of events and remain analytically weak. Common defects include:

• purchase_completed firing when checkout opens rather than when payment succeeds;
• form_submitted firing on a button click even when validation fails;
• screen_viewed firing during preload without a visible screen;
• program_completed firing when progress is saved;
• two event names representing the same action;
• one generic event representing several different objects;
• automatic screen or click events being mistaken for business outcomes;
• success and retry paths both producing the same event.

99ways has encountered implementations where an event existed but lacked the context required to identify the relevant program, day, or step, and cases where a view event fired without the related screen being visibly presented. The problem was not data transport. The event’s meaning was false or incomplete.

Validate event semantics against real state changes

For every critical event, the audit should verify:

1. Actor: Which person, account, service, or anonymous client performed the action?
2. Object: What product, order, plan, program, step, lead, or content item was affected?
3. State transition: What became true that was not true before?
4. Trigger boundary: What exact product or backend condition fires the event?
5. Multiplicity: Should it occur once per transaction, once per session, or repeatedly?
6. Failure behavior: What happens on validation failure, retries, cancellation, or reversal?
7. Authority: Is the event based on UI intent, application state, or authoritative backend confirmation?

PostHog can document event definitions and typed property groups, but schema features do not make an incorrect trigger correct. See Schema management.

This audit section establishes whether the current events are valid. The companion Event Tracking Plan will explain how to design the naming and trigger contracts from the beginning.

Pass evidence: a sampled set of critical events replayed against real product flows, with raw payloads and source-code or webhook confirmation showing that the trigger matches the documented meaning.

7. Verify properties, data types, coverage, and queryability

A correct event without the right properties may still be unusable.

The audit should inspect whether each critical event carries the dimensions and join keys required for later analysis. Depending on the event, these may include:

• order_id, transaction_id, subscription_id, or invoice_id;
• product_id, plan_id, program_id, step_id, or content_id;
• numeric value and ISO currency;
• quantity, discount, tax, shipping, refund, or net-value fields;
• source, campaign, ad group, ad, click, partner, and landing identifiers;
• app version, environment, host, country, device, and consent state;
• account, organization, workspace, or tenant ID;
• status, reason, result, or lifecycle stage;
• schema or implementation version when migrations require it.

Four tests matter.

Property presence

Measure missingness by event, source, SDK, app version, environment, and time period. A property present in 95% of web purchases and absent from every mobile purchase is not a minor documentation issue.

Semantic consistency

The same property name must mean the same thing. revenue cannot be cents in one SDK and dollars in another. plan cannot sometimes mean the selected plan and sometimes the active subscription. campaign_id cannot contain a name in one source and an ID in another.

Data-type consistency

Numeric facts should be numeric when calculations require them. Timestamps need a defined timezone and format. IDs should generally remain strings even when they contain only digits. Booleans should not alternate between true, 1, and "yes".

Queryability

A clean business metric should be constructible without parsing labels, maintaining a long list of aliases, manually deduplicating obvious repeats, or joining on mutable names. If every dashboard needs a different workaround, the data model is not decision-ready.

PostHog’s Data Management area exposes event definitions, observed property types, first and last seen dates, verification, history, and ingestion warnings. These are useful audit surfaces, not substitutes for sampling raw events and reproducing metrics. See Data management.

The detailed design of event and property contracts belongs in Event Tracking Plan.

Pass evidence: property coverage and type profiles for critical events, a list of semantic collisions, and at least one clean query for every decision in scope.

8. Verify browser/server collection, environments, consent behavior, and deduplication

A trustworthy implementation assigns an authoritative collection path to each important fact.

Browser events are appropriate for what the user saw or attempted. Server or webhook events are usually stronger for facts such as payment capture, subscription renewal, refund, entitlement activation, or CRM stage change. Sending both can improve observability, but it can also double the event unless the relationship is designed explicitly.

Build a collection matrix:

Business fact	Browser/app signal	Server or webhook signal	Authoritative event	Deduplication key
Checkout started	User reaches checkout	Optional checkout object created	Defined by the business question	checkout_id
Purchase	Confirmation page viewed	Payment/order confirmed	Usually backend confirmation	order_id or transaction_id
Subscription renewal	Usually none	Billing webhook confirms renewal	Billing webhook	invoice_id or renewal transaction ID
Refund	UI may display status	Processor or commerce webhook	Financial system event	refund_id

The audit should test:

• duplicate events from browser plus server;
• webhook and SDK retries;
• refreshes of confirmation pages;
• missing or reused transaction IDs;
• out-of-order lifecycle events;
• delayed server events;
• stale timestamps;
• development and staging traffic entering production;
• QA, employee, monitoring, and bot traffic;
• consent accepted, rejected, and changed mid-journey;
• blockers or network failures affecting client-side collection;
• transformations that silently alter or drop fields.

PostHog server SDKs do not attach a browser $session_id automatically. If a backend purchase belongs to the frontend session, the session ID must be passed deliberately; otherwise the purchase may be connected to the person but not the originating web session. See PostHog sessions.

Internal and test traffic should be handled intentionally. The 99ways guide to PostHog internal user filtering covers one part of that control. Filters should themselves be tested: a missing email property, inverted condition, or unfiltered staging host can create a false sense of cleanliness.

Define authoritative event sources and deduplication rules

Deduplication is not just a dashboard filter. The implementation should have one of these designs:

1. one authoritative event source for the business fact;
2. an idempotent event producer keyed by a unique business ID; or
3. a documented query-level rule that selects the authoritative record while preserving diagnostic signals separately.

Pass evidence: repeated test journeys and webhook retries produce the intended number of logical business events, with internal and non-production activity excluded from decision queries.

9. Reconcile purchases, revenue, refunds, and renewals with business systems

Revenue is trustworthy only when PostHog can be reconciled to the system where money or entitlement actually changed.

Start by defining the value being reported:

• gross order value;
• captured payment value;
• net revenue after discounts;
• net revenue after refunds and chargebacks;
• contribution after variable costs;
• first-payment value;
• realized subscription revenue through a fixed horizon;
• expected lifetime value.

These are not interchangeable.

PostHog’s revenue guidance recommends capturing revenue where money changes hands and including numeric value, currency, product, and subscription identifiers. See Capturing revenue with PostHog. The audit must go further by confirming that the chosen event and value match the business definition and reconcile over time.

For a representative period, compare PostHog with Shopify, Stripe, RevenueCat, the application database, the CRM, or another operational system at the transaction level.

Useful calculations include:

Purchase match rate

authoritative purchases matched to one valid PostHog purchase / eligible authoritative purchases

Duplicate rate

extra PostHog purchase records for matched authoritative purchases / matched authoritative purchases

Revenue variance

(PostHog revenue - authoritative revenue) / authoritative revenue

Do not impose one universal pass threshold. A behavioral funnel may tolerate a small consent-related coverage gap that would be unacceptable for financial reporting or bid optimization. The audit should define the acceptable tolerance by decision and explain every material unmatched category.

Test:

• successful purchases;
• failed and abandoned payments;
• duplicate webhook delivery;
• multiple currencies;
• discounts and coupons;
• tax and shipping treatment;
• full and partial refunds;
• chargebacks;
• subscription starts, renewals, pauses, cancellations, and expirations;
• order edits and delayed fulfillment changes;
• test orders and zero-value orders.

The 99ways article on currency conversion and revenue tracking in PostHog provides implementation context. The audit’s job is to prove that the final report reconciles, not merely that a currency expression exists.

Pass evidence: a transaction-level reconciliation table, categorized unmatched records, documented value definition, and aggregate totals by date and currency.

10. Validate attribution rules and ad-cost matching

Attribution is a rule applied to observed journeys, not an objective account of causal influence.

The audit should document:

• the attribution unit: session, person, account, order, or subscription;
• first-touch, last-touch, session-entry, or another rule;
• the lookback and conversion windows;
• how direct and returning visits are treated;
• how cross-device and consent-constrained journeys are classified;
• how campaigns are matched to ad-platform spend;
• how campaign renames and source aliases are handled;
• which currency and timezone are used;
• whether refunds and renewals are attributed back to the original acquisition source.

PostHog’s current Marketing Analytics product can ingest advertising cost data and match conversion goals principally through utm_source and utm_campaign. It can use campaign names or campaign IDs, and the feature is currently documented as opt-in beta. See Marketing Analytics.

That makes campaign-level reporting possible when naming and IDs align. It does not, by itself, guarantee ad-level ROAS.

To calculate observed ROAS for each ad, the implementation needs:

1. an ad-level identifier captured at entry and preserved to the purchase;
2. realized purchase value attributed under an explicit rule;
3. ad spend available at the same ad identifier and date grain;
4. consistent currency and timezone treatment; and
5. a query or modeled table joining the two without double-counting.

The calculation is:

Observed attributed ROAS for an ad = realized revenue attributed to that ad / spend for that ad

Distinguish observed attribution from incremental return

This is not incremental ROAS. It describes revenue assigned under the chosen attribution rule. Causal incrementality requires a different design, such as a controlled experiment or credible holdout.

Expect some differences from ad-platform reporting. Platforms may use their own identity graphs, view-through credit, modeled conversions, attribution windows, click definitions, and timezone rules. The audit should reconcile and explain differences, not promise identical totals.

If paid acquisition is not material, ad-level attribution may be unnecessary. If paid acquisition drives the business, inability to link source and realized value is a meaningful limitation that should be stated explicitly.

Pass evidence: an attribution specification, source and campaign mapping table, spend-to-conversion join test, unattributed bucket analysis, and a reproducible campaign or ad-level report at the granularity the business actually needs.

11. Validate metrics and queries—and trace a real purchase backward

A clean event stream can still produce a wrong dashboard.

Audit the saved insights, actions, dashboards, and HogQL queries used for real decisions. For each critical metric, verify:

• event or action definition;
• person, account, session, or event counting unit;
• eligible denominator;
• date and timezone field;
• conversion window;
• first or repeated occurrence behavior;
• event property versus person property filters;
• internal, bot, QA, and environment exclusions;
• refund and duplicate treatment;
• attribution rule;
• currency conversion;
• handling of missing values;
• owner and documentation.

Rebuild at least the highest-value metrics independently. A purchase count might be checked through a direct event query, a unique order_id query, and the authoritative order export. A funnel might be rebuilt using explicit events rather than a legacy Action. An ad report should be compared with a transaction-level join rather than trusted because the chart renders.

The end-to-end purchase trace

This is the strongest practical proof of the implementation.

1. Select a real, non-test purchase from the commerce, billing, or backend system.
2. Search PostHog by order_id, transaction_id, subscription ID, customer ID, or another authoritative key.
3. Confirm that exactly one logical purchase exists under the agreed event definition.
4. Compare amount, currency, product, discount, tax, refund status, and timestamp with the system of record.
5. Inspect the associated person or account and confirm that relevant anonymous and known events are connected.
6. Locate the landing or entry session and verify the expected initial and session source fields.
7. Confirm that campaign, ad group or ad set, ad, and click identifiers are preserved to the level required.
8. Map the ad identifier to cost data for the same platform, date, currency, and account.
9. Repeat the procedure for purchases from several sources, devices, journeys, and lifecycle types.
10. Reproduce the relationship in aggregate and categorize every material unmatched or multiply matched record.

A single successful trace does not prove coverage. Aggregate reconciliation does not prove that individual joins are correct. The two tests complement each other.

The audit should end with a decision trust matrix:

Decision	Required evidence	Trust status	Limitation or action
Product funnel by device	Valid events, device property, stable session behavior	Safe / Conditional / Unsafe	Document defect and remediation
Campaign revenue	Source persistence, identity, purchase reconciliation	Safe / Conditional / Unsafe	State unattributed share and scope
Ad-level ROAS	Ad ID, realized value, ad-level spend join	Safe / Conditional / Unsafe	Build missing ID or cost model
Subscription LTV by source	Customer and subscription identity, renewal/refund events	Safe / Conditional / Unsafe	Define horizon and lifecycle rules
Experiment result	Assignment, exposure, outcome integrity	Safe / Conditional / Unsafe	Route to experimentation-system audit

This is more useful than one overall score. It tells management exactly which decisions the implementation can support today.

12. Establish production QA, monitoring, ownership, and governance

An audit is a snapshot unless the implementation has controls for change.

Production QA

Run representative flows in production or a production-equivalent environment:

• new anonymous visitor;
• returning anonymous visitor;
• signup and login;
• logout and shared-device reuse;
• cross-domain or checkout transition;
• web-to-app or app-to-web handoff;
• successful, failed, and repeated purchase;
• refund and renewal;
• accepted, rejected, and delayed consent;
• blocked script or failed network request;
• each major device, browser, app version, and market;
• internal and QA users;
• campaign links from real ad-platform preview tools.

Monitoring

Monitor the conditions most likely to invalidate decisions:

• critical event volume stops or spikes;
• required property missingness changes;
• event types or currency fields drift;
• duplicate transaction IDs increase;
• unmatched orders or revenue variance grows;
• direct or unknown source share changes unexpectedly;
• identity merge rates or anonymous conversion share shifts;
• ingestion warnings appear;
• data-pipeline destinations or transformations fail;
• new app versions change event behavior;
• dashboards depend on stale Actions or deprecated events.

PostHog provides event descriptions, verification status, property types, change history, ingestion warnings, and pipeline logs. These are useful controls when teams assign owners and review them. They are not self-enforcing governance.

Governance

At minimum, define:

• an owner for every critical metric and event family;
• a source-controlled or centrally governed tracking specification;
• release acceptance criteria for analytics changes;
• event and property deprecation rules;
• schema-change review;
• a process for annotating launches and incidents;
• dashboard ownership and definition review;
• a re-audit trigger after major product, identity, checkout, consent, ad-platform, or billing changes.

Pass evidence: a QA runbook, monitoring set, ownership matrix, change-control process, and dates for the next review.

The 12-point PostHog audit scorecard

A practical scorecard should record evidence and decision impact rather than only yes or no.

#	Check	Evidence to capture	Severity if failed
1	Decision scope and systems of record	Question matrix, definitions, project scope	Critical when no metric has an agreed meaning
2	Acquisition identifiers at entry	Test links, raw landing events, platform field map	Critical for paid-source reporting
3	Source persistence	Initial/session/latest property trace	High to critical for attribution
4	Cross-system continuity	Domain/app/checkout transition tests	Critical when journeys split before conversion
5	Identity architecture	Person traces, ID map, merge/reset tests	Critical for user, account, LTV, and experiment analysis
6	Event semantics and triggers	Trigger tests, raw payloads, code/webhook references	Critical for affected business outcomes
7	Properties and queryability	Coverage, type, and semantic profiles	High when required dimensions or join keys are absent
8	Collection and deduplication	Browser/server matrix, retry and consent tests	Critical for purchases and conversions
9	Revenue reconciliation	Transaction match and variance tables	Critical for revenue and ROAS
10	Attribution and spend matching	Attribution specification and cost join	Critical when budget allocation depends on it
11	Metric and query validation	Rebuilt metrics and purchase traces	High to critical depending on decision
12	QA and governance	Runbook, monitoring, owners, change history	High because trust will decay without it

Severity should be tied to the decision at risk. A missing content_id may be medium for an executive revenue dashboard and critical for content recommendation analysis.

What a PostHog audit should deliver

A serious audit should produce:

1. Decision trust matrix: which decisions are safe, conditional, or unsafe.
2. System map: domains, apps, SDKs, servers, checkouts, billing, CRM, ad platforms, warehouses, and pipelines.
3. Acquisition and attribution map: UTMs, click IDs, campaign/ad identifiers, persistence, and cost joins.
4. Identity map: canonical IDs, anonymous-to-known transitions, account/group entities, session continuity, and accepted blind spots.
5. Critical-event assessment: meaning, trigger, source, multiplicity, authority, properties, and queryability.
6. Property-quality report: missingness, data types, semantic collisions, and schema drift.
7. Browser/server collection matrix: authoritative source and deduplication rule for each business fact.
8. Revenue reconciliation: matched, missing, duplicate, mismatched, refunded, and unattributed transactions.
9. Metric validation: reconstructed funnels, revenue, attribution, and management queries.
10. Prioritized remediation plan: issue, evidence, decision at risk, severity, owner, recommended fix, and verification test.
11. Production QA evidence and monitoring plan.
12. Handover: documentation, owners, and re-audit triggers.

The deliverable should make engineering action possible. “Your tracking needs improvement” is not a finding.

What a PostHog audit cannot prove

Even a strong audit has limits.

• It cannot recover journeys that privacy controls, browser isolation, device switching, or missing identifiers made unobservable.
• It cannot make attribution causal. Observed ROAS is not incremental ROAS.
• It cannot validate the business value of a metric merely because the metric is technically correct.
• It cannot prove future releases will preserve tracking without monitoring and governance.
• It cannot validate an experimentation system’s assignment, exposure, and statistical inference. Use the Experimentation System Audit for that.
• It cannot replace a tracking plan when the underlying event model was never designed. Use the Event Tracking Plan to redesign the model.
• It cannot make PostHog the financial ledger. Finance and operational systems remain authoritative for their own facts.

Frequently asked questions

What is a PostHog audit?

A PostHog audit is a system-level review of whether acquisition data, identity, events, properties, revenue, attribution, queries, and operational controls work together well enough to support defined business decisions. It produces evidence, a trust assessment by decision, and a prioritized remediation plan.

How do I know whether my PostHog data can be trusted?

Choose a decision and trace the required facts end to end. For revenue attribution, take a real order from the source system, find the matching PostHog purchase, verify value and identity, trace the person to the landing source, and then reconcile the same chain in aggregate. Trust should be granted per decision, not to the project as a whole.

What should a PostHog audit check?

It should check decision definitions, acquisition IDs, source persistence, cross-domain and app continuity, identity, event triggers, property schemas, browser/server collection, deduplication, revenue reconciliation, attribution, saved queries, production QA, monitoring, and governance.

Is seeing events in PostHog enough?

No. It proves ingestion, not meaning or completeness. An event can fire too early, fire twice, belong to the wrong person, omit the order ID, contain the wrong currency, or lose its acquisition source while still appearing normally in PostHog.

Does PostHog automatically preserve UTM attribution?

PostHog automatically captures standard UTMs that are present and stores them on events, person properties, and session-entry properties. Attribution still fails when parameters are stripped, names are inconsistent, identity changes, storage resets, users cross domains or browsers, or conversion events cannot be joined to the original landing journey.

Why do UTMs appear on pageviews but not purchases?

The usual causes are identity fragmentation, a separate checkout or domain, a backend purchase using a different distinct_id, consent or storage resets, or a conversion query that reads the wrong property. Audit the landing-to-purchase identity and session chain rather than assuming UTM capture itself failed.

How should identity be designed in PostHog?

Use the simplest identity model that supports the decisions in scope. Anonymous session analysis may need only reliable device and session IDs. User retention needs a stable user ID. B2B analysis may need account or group IDs. Source-to-renewal reporting may also require transaction, customer, and subscription IDs. The key is consistency across environments and explicit linking at identity transitions.

How do you reconcile PostHog revenue with Shopify, Stripe, or a backend?

Match records by stable transaction keys, compare counts and values, identify duplicates and missing events, and classify differences such as consent loss, failed payments, refunds, retries, test orders, currency handling, and delayed webhooks. Reconcile both individual records and aggregate totals.

Can PostHog calculate ROAS for each ad?

It can support ad-level ROAS when the implementation captures a stable ad identifier, preserves it to the conversion, records realized value, and joins it to ad-level spend at the same identifier, date, currency, and account. PostHog’s native Marketing Analytics currently emphasizes campaign matching through source and campaign fields, so ad-level reporting may require additional properties, HogQL, or warehouse modeling.

What is the difference between a PostHog audit and an event tracking plan?

A PostHog audit validates whether the existing implementation is trustworthy. An event tracking plan designs the event names, triggers, properties, identities, metric definitions, owners, and QA rules that should be implemented. The audit finds and prioritizes defects; the plan specifies the target data model.

Is PostHog the source of truth for revenue?

Usually not by itself. The payment processor, commerce backend, billing system, or finance system is authoritative for captured and refunded money. PostHog becomes the analytical representation that connects those facts to acquisition and behavior. The audit verifies that representation.

How often should PostHog be audited?

Audit during initial implementation, after major identity, checkout, billing, consent, mobile, or attribution changes, before relying on new executive or advertising reports, and periodically when the system changes frequently. Continuous monitoring should detect critical drift between formal audits.

The next useful decision

If your PostHog project contains data but cannot trace acquisition to realized value, reconcile purchases, or explain which reports are safe, the next step is an implementation audit—not another dashboard.

See what a PostHog expert should own and how 99ways approaches the work.