The Need for Conversion Tracking
Like any growth-minded team, we want to understand where our customers come from and which problems we're solving most effectively. That means knowing which ads lead to signups - and ultimately to active users.
Tracking "conversions" requires two things: a clear definition of what a conversion is, and a reliable way to signal Google when it happens. For us, a key conversion is when a user signs up after clicking an ad and landing on our page.
The complication? We use AWS Cognito for authentication. When a user creates an account or signs in, they're temporarily redirected away from our site to Cognito's managed login page — breaking the chain between ad click and confirmed signup.
The Workarounds We Considered
There are a few common approaches to this problem:
- Build a custom login UI — Skip Cognito's managed login page entirely, design your own frontend, and handle the user flows with backend endpoints that still call Cognito under the hood. More control, but significant engineering overhead.
- Fire a Lambda on signup — Trigger a backend Lambda function on signup completion that sends the conversion event to Google, assuming you can pass the required Google metadata through the entire signup flow.
Both are valid, but we wanted something simpler — a way to track conversions without touching our existing backend or UI, but we kept seeing online that the suggested approach was to use one of the above approaches. Further, when we discussed with technical support at google they recommended leveraging google tag manager - but again we don't control the code on Cognito so we couldn't add the required HTML to those pages. Potentially there is a better approach, but the one we found, outline below, seemed quite straightforward comparatively.
The Unlock: AWS Cognito's State Field
It turns out Cognito has exactly what we need built in.
When initiating a signup session with Cognito's managed login, you can pass a state field. Cognito holds onto this value and returns it to you once the user lands back on your redirect URI after completing the flow. This is perfect for our use case: we pass the gclid (Google's click identifier, which ties the session back to the originating ad) through the state field, and it survives the round trip through Cognito intact.
A Few Technical Details Worth Knowing
- This only works with Cognito's managed login page. If you're using a custom UI, this approach doesn't apply.
- The state field has a size limit. We recommend encoding or compressing whatever data you need to preserve — this also keeps the URL cleaner for users, who will only see an encoded string rather than a sprawl of raw parameters.
- Watch out for state mutations in other tooling. If you're using AWS Amplify, it may alter the state variable during the redirect flow. Double-check the encoding on return.
Putting It All Together
Once the user completes signup and returns to our redirect URI, we have everything we need. We read the gclid back out of the returned state, then fire the gtag() command to send the conversion event to Google — cleanly, without any backend changes or UI redesigns.
Platforms like Google and Meta can use conversion data to improve ad targeting over time, making your spend go further. Whether you lean into their automated optimization or prefer to tune things yourself, having accurate conversion data is foundational either way.
If you found this useful, we'd love for you to try our tools and share what you think. Sign up at bluelanternsecurity.io and send us feedback at [email protected].
Want to go deeper?