feat(cli): associate signed-in HeyGen account with telemetry - #2020
Conversation
Sign-in telemetry currently attributes everything to the anonymous install id, so the sign-in funnel can be counted but a completed sign-in can't be tied to the account it produced. This associates the two. - On a completed sign-in, emit a PostHog `$identify` alias whose `$anon_distinct_id` is the install's anonymousId, so events recorded before sign-in stitch to the same person, and tag `auth_login_completed` with the account identity (the pre-plumbed `distinctId`). - `/v3/users/me` exposes no opaque user_id, so the identity key is the account email, falling back to username (single `identityKey` helper). - Both no-op under the `telemetry disable` opt-out and only fire after the user chooses to sign in. Privacy disclosure updated in lockstep, since this is the first PII the CLI attaches: the first-run telemetry notice and the telemetry section of docs/packages/cli.mdx now state that signing in links your account email to your usage. Tests: identifyUser payload + no-op, completion attribution incl. username fallback and no-identity-on-reject/empty. Verified end-to-end against the built CLI: pre-auth events anonymous, $identify carries $anon_distinct_id, completion carries the account email.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
Review gating item: identityKey is `email ?? username`, but the first-run notice and cli.mdx said only "email", so an emailless account's username would reach PostHog undisclosed. `/v3/users/me` treats email as optional (pickString), so the fallback is live code, not dead — disclose it rather than assert an unverifiable email guarantee. Both surfaces now say "email, or username if the account has no email". Also soften the identityKey comment: it implied username is "less identifying", but HeyGen usernames are often email-shaped, so the note now states username is a fallback, not a privacy win.
|
Thanks both. Addressed in cd02297. Gating — email-vs-username disclosure gap (tai #1 / Rames): disclosed the fallback rather than dropping it.
Nit — "less identifying" comment (tai): softened. The Non-gating, not doing now (with reasons):
Waiting on green. |
What
Follow-up to the sign-in telemetry (#2000). That change counts the sign-in funnel but attributes everything to the anonymous install id, so a completed sign-in can't be tied to the account it produced. This associates the two.
$identifyalias whose$anon_distinct_idis the install's anonymousId (so events recorded before sign-in stitch to the same person), and tagauth_login_completedwith the account identity via thedistinctIdarg that was pre-plumbed for this./v3/users/mereturns no opaque user_id, so the identity key is the account email, falling back to username (singleidentityKeyhelper; flip the order there to prefer the less-identifying username).--api-keypaths. Completion now fires after the identity probe so it can carry the identity; if the probe fails transiently the sign-in still records as completed, just without an identity.Privacy
This is the first PII the CLI attaches, so the disclosure is updated in the same PR:
showTelemetryNotice), anddocs/packages/cli.mdxboth now state that signing in links your account email to your usage. Everything still no-ops under
hyperframes telemetry disable/HYPERFRAMES_NO_TELEMETRY=1, and identification only happens after the user chooses to sign in.Tests & verification
identifyUserpayload + no-op on empty; completion attribution including the username fallback and the no-identity cases (transient probe failure, rejected key). 34 tests green, typecheck + lint + fallow clean.cli_command(anon) →auth_login_started(anon) →$identify(distinct_id = email,$anon_distinct_id= install id) →auth_login_completed(distinct_id = email). The live/v3/users/mecall succeeded; the PostHog POST was intercepted so nothing hit production analytics.Note: no data lands until a CLI release ships with this.