Skip to content

Signup attribution and UTM

How we know where a signup came from: which ad or channel brought the visitor in, and which on-site action converted them. The model is borrowed from Instaffo's proven attribution system and adapted to the Kwilo site/app split.

Engineering reference

Implementation detail, file map, and the "adding a key" checklist live in the main repo: docs/operating/attribution-and-utm.md. This page is the product-level overview.

Why it exists

Marketing spends money to bring people to kwilo.ai. Without attribution we cannot answer two questions that decide where the next rupee goes:

  • What acquired them? Which campaign, channel, or ad first brought the visitor in. Drives channel ROI.
  • What converted them? Which on-site page and CTA they actually clicked to start signup. Drives landing-page and funnel decisions.

Before this, the marketing site captured the data but the app threw most of it away at signup, and an organic visitor who converted showed up as "unknown source." We were flying blind on half the funnel.

The two kinds of attribution

External — what brought them to the site. Standard UTM parameters plus ad-network click IDs (Google, Meta, Microsoft). Captured dual-touch:

  • First-touch freezes on the visitor's very first arrival and never changes. Answers "which channel acquired them," even if they later return organically.
  • Last-touch updates on every fresh visit. Answers "which click closed them."

We keep both, because picking one throws away half the marketing signal.

Internal — what on-site action converted them. When a visitor clicks a CTA that sends them from kwilo.ai to the app signup, that action is tagged with a fitting internal UTM describing the surface and the button (for example, the /individuals hero "Generate" button). This is separate from external UTM, so an organic visitor is no longer recorded as blank-source: we still know they converted from the individuals hero.

The journey

  1. Visitor arrives from an ad. The campaign parameters are captured into a cookie shared across kwilo.ai and app.kwilo.ai.
  2. First-touch is frozen; last-touch updates if they return from another ad.
  3. They click a signup CTA. The handoff to the app carries their intent (persona, mode, topic), the external attribution, and a fitting internal UTM for the action they took.
  4. They sign up (email, phone, or Google). All of it is attached to the new user record.
  5. Analytics and marketing reports can now attribute the signup to both the acquisition channel and the on-site action that converted it.

What we store

On the user record: the external UTM (first and last touch), the ad-network click IDs, the internal UTM for the converting action, plus the referrer and landing page. Every conversion surface (signup today, lead forms tomorrow) reuses the same shared storage, so attribution is defined once and never re-invented per feature.

Compliance note (DPDP)

Attribution parameters are stored on the user record and count as personal data under the DPDP Act. They are captured via a domain-scoped cookie governed by our cookie consent flow. Click IDs and UTM values are retained for marketing analysis; account deletion removes them along with the user.