PostHog / PostHog/posthog

Feature Request: cost-per-conversion is misleading when the conversion event is offset in time from acquisition (refunds, repeat purchases, churn)

Open
#57,255 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement feature/marketing-analytics
Dominant language
Python
Stars
39.9k
Forks
3.4k
Avg merge
6h 51m
Merged PRs (30d)
232

Description

Feature request

Is your feature request related to a problem?

A customer using marketing analytics with Google Ads set up "Order refunded" as a conversion goal and is reading "Cost per refunded order" as their indicator of how much they're paying to acquire users who later refund. The number they see is misleading.

Today, "Cost per X" is calculated at the period level: total ad spend in the period/count of X events in the period. For their 7-day window: €1700 spent / 10 refunds = €170 per refund.

The problem is that the refunds in any given week are tied to orders placed weeks or months earlier. The €1700 of ad spend in the numerator has no relationship to the campaigns that originally acquired the users who refunded this week. As a result, "Cost per refunded order" doesn't measure what the customer thinks it measures, and they're making decisions based on a number that conflates two unrelated periods.

The customer's own framing: "if we acquire a user and pay for that acquisition, and they later refund an order, the cost of that refunded user should be based on how much we paid to acquire them, rather than the total weekly spend."

The same mismatch shows up for any conversion goal that's structurally offset from acquisition: refunds, cancellations, churn, repeat purchases, etc. The current calculation is fine for sign-ups and first purchases (where the conversion happens shortly after the click), but breaks down everywhere else.

Additional context

From: https://posthoghelp.zendesk.com/agent/tickets/54247 (moved to PostHog: https://us.posthog.com/project/2/support/tickets/61097)

Debug info

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by locating the current period-level Cost per X calculation and the conversion attribution logic, then determine how delayed events such as refunds relate to their original acquisitions. Done should include an agreed attribution model for offset conversions and coverage for refunds, repeat purchases, cancellations, or churn.

Written by the indexing model from the issue text.

Assessment

Domain
analytics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.