Lean Tracking Plan: Global SaaS Funnel

Tool-agnostic. It works with GA4, Mixpanel, Amplitude, PostHog or Segment. I didn't find a product-marketing context file, so I assumed no existing tracking and no chosen tool. Last updated: 2026-10-04.

1. Decisions this plan informs

2. Conventions

• Event names: object_action, lowercase snake_case, past tense. There are 5 funnel events plus 1 optional.
• Properties: snake_case with enumerated values. Don't send free text.
• Identity: use an anonymous anonymous_id (first-party, random) before signup. After signup, use an opaque account_id (internal UUID). Never use email, name, or phone as an ID.
• Server-side events: fire workspace_signed_up, first_project_created and subscription_started from the backend. This is more reliable and ad-blocker-proof, and it ensures the event fires only once.

3. Events

Funnel events

Optional (add only if needed)

Properties

Common properties (attach to every event):

Event-specific properties:

4. Funnel and conversions

landing_page_viewed → demo_requested (branch, not a required step) → workspace_signed_up → first_project_created → subscription_started

• Primary conversions: workspace_signed_up, first_project_created (activation), subscription_started.
• Secondary conversion: demo_requested.
• Funnel window: 30 days from first touch to signup, 90 days to paid. Report by region, utm_medium and plan_id.
• Counting: once per workspace, except subscription_started, which counts once per subscription.

5. Validation steps

1. Spec review: Check every event and property against this document. Reject undocumented properties through a schema/allowlist in the tag or SDK layer.
2. Staging test: Run the full funnel on staging with debug tools (GA4 DebugView, GTM Preview or the vendor's live event view). Confirm that each event fires once, in order, with the right property types.
3. Duplicates: Reload the thank-you page, double-click submit and use the back button. Event 2–5 must not re-fire.
4. Server vs. client parity: Compare backend records (demos, workspaces, projects, subscriptions) with analytics counts for a day. Aim for a gap under 2–3%, and investigate anything beyond that.
5. Identity stitching: Confirm anonymous_id links the landing page to signup, and account_id persists after signup. Check that UTMs on the first touch carry to events 2–5.
6. Cross-region and cross-device: Test in at least one EU, US and APAC locale, on mobile and desktop, with an ad blocker on and off.
7. Consent test: With consent denied, confirm no analytics cookies or client events fire (see section 6). Verify that essential server-side counts follow your legal basis.
8. PII scan: Search sample payloads and warehouse columns for @, phone patterns and name-like strings. Run it automatically each week.
9. Post-launch monitoring: Set alerts for a >30% day-over-day drop in any event, a sudden spike in duplicates, or a new unexpected property.

6. Privacy safeguards

• No personal data in events: No email, name, phone, IP address, free-text fields, company name, or payment details. Use bands (company_size_band) and enumerations instead of raw values. Form fields stay in the CRM, not in analytics.
• Identifiers: Opaque, random, first-party IDs only. Don't use hashed email as a user ID (it's still personal data under GDPR). Don't pass IDs to ad platforms without consent.
• Consent: Use a consent management platform with region-aware defaults: opt-in for the EU/UK, Brazil and similar, and opt-out where law allows (for example, parts of the US). Use consent mode or equivalent, and block client-side tracking until consent is granted. Respect Global Privacy Control signals.
• Geo: Resolve country at ingestion, then discard the IP. Turn on IP anonymization or "don't store IP" in your tool.
• URLs and referrers: Strip query strings except an allowlist of utm_*. Log referrer_domain only. This prevents tokens, emails or invite codes in URLs from leaking.
• Data residency and transfers: Choose an EU-hosted region for EU traffic, or use SCCs/DPA with the vendor. Record vendors in your processor list.
• Retention and deletion: Set event retention to 14 months or less (or per your policy). Support deletion by account_id and anonymous_id, and propagate deletions to downstream tools.
• Access: Restrict raw event access to named roles. Use aggregates in dashboards.
• Governance: Any new event or property needs a plan update and privacy sign-off. Keep a change log.

7. Implementation notes

• Use a single data layer or SDK wrapper (track(name, props)) that enforces the schema and strips unknown keys. This is the main defense against accidental PII.
• Persist first-touch UTMs in a first-party cookie or local storage (with consent), and send them to the backend at signup so server-side events can carry them.
• Send subscription_started from the payment webhook with an idempotency key (the subscription ID) to prevent duplicates.
• Choose the tool based on need. Marketing-site attribution suits GA4. Funnel and cohort analysis suits Mixpanel, Amplitude or PostHog. Segment is worth it only if you need routing to several tools.

8. Open questions

1. Which analytics tool or tools are you using or planning?
2. Is demo_requested a separate path, or can a demo requester also sign up directly? This changes how to read the funnel.
3. Is there a free trial or freemium plan? This affects plan_type and the subscription_started definition.
4. Which regions need strict opt-in consent (EU/UK, others)?

I can turn this into a spreadsheet or JSON schema (for runtime validation), or draft the data layer code for your stack, if that would help.