refactor: identify report analytics by the generating machine's anon id - #27
Merged
Conversation
The report's PostHog distinct id was the per-run reportId, so a run's CLI events (keyed by the machine anon id) and its report views never resolved to the same person. That broke person-based funnels across the CLI→report boundary and let internal report activity slip past the anon-id cohort. Use the embedded generatedByAnonId as the report's distinct id so both surfaces share one person. pw_report_id stays on every event as a property for per-run slicing; the now-redundant pw_generated_by property is dropped. Not backward compatible: older reportId-keyed report persons won't merge, which is fine going forward.
blimmer
force-pushed
the
refactor/posthog-anon-id-identity
branch
from
May 27, 2026 20:35
b280b2e to
28ba845
Compare
blimmer
enabled auto-merge (squash)
May 27, 2026 20:36
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The report's PostHog
distinct_idwas the per-runreportId, so a run's CLI events (keyed by the machine anon id) and its report views never resolved to the same PostHog person. That broke person-based funnels across the CLI→report boundary and let internal report activity slip past the anon-id "internal" cohort.This identifies the report by the embedded
generatedByAnonId— the same distinct id the CLI already uses — so both surfaces are one person.pw_report_idstays on every event as a property for per-run slicing; the now-redundantpw_generated_byproperty is dropped. Not backward compatible (fine by design): olderreportId-keyed report persons won't merge.Depends on #26 to actually run the touched analytics suites in CI — will rebase once that lands.
Review focus
The tradeoff of anon-id-as-identity: views of a shared/uploaded report attribute to the generator's anon id rather than grouping per-report. For a diagnostic tool that's arguably more correct, and it's no worse than the prior
reportIdscheme (which also couldn't tell viewers apart). Falls back toreportIdonly when no anon id was embedded.Commits
b280b2e— identify report analytics by the generating machine's anon id