Tired of your systems only remembering the last thing a user did? A senior DevOps lead breaks down why ‘last-click’ issues happen at the infrastructure level and provides three battle-tested fixes, from quick hacks to a full architectural redesign.

Last-Click Blinders: Why Your Architecture Is Losing the First Touchpoint

I still remember the pager alert. 9:15 PM on a Thursday. Not a server down, not a database CPU spike. The alert was from a P1 Jira ticket, subject: “URGENT – ALL MARKETING DATA IS WRONG”. The Head of Marketing was convinced our new ad campaign was a catastrophic failure because our analytics dashboard showed 100% of conversions coming from “direct traffic”. Every single one. A multi-million dollar campaign was apparently generating zero attributable sign-ups. The problem wasn’t the ads, though. The problem was our architecture had a bad case of amnesia, and it was about to cost us a fortune.

The Root of the Amnesia: Statelessness is a Double-Edged Sword

We build our web applications to be stateless for a reason. It’s how we scale. A user hits our load balancer, gets routed to web-app-az1-04, and then their next click might go to web-app-az2-11. These servers are cattle, not pets. They don’t know each other and they certainly don’t share memories. This is great for resiliency, but terrible for tracking a user’s journey.

The “first click”—the one from the Google Ad or the Facebook campaign—hits one server. That server sees the UTM parameters in the URL, but it has no standard way to tell the *next* server in the fleet about it. By the time the user signs up ten minutes later on a completely different server instance, that precious initial context is gone. The final conversion server only sees its own request, which looks like the user just typed our URL into their browser. Hence, “direct traffic”. It’s not a bug in the analytics software; it’s a hole in our infrastructure’s memory.

The Fixes: From Duct Tape to a New Foundation

We’ve all been there. The business is screaming, and you need a fix now, but you also need a fix that will last. Here’s how I break down the solutions, from the immediate patch to the long-term architectural shift.

Solution 1: The ‘Get Marketing Off My Back’ Quick Fix

Let’s be honest, sometimes you just need to stop the bleeding. The fastest way to persist that first-click data is to store it on the client side. A little bit of JavaScript can grab the UTM parameters from the URL on the first visit and stuff them into a cookie or the browser’s localStorage.

// Super simple vanilla JS example to run on your landing pages
document.addEventListener('DOMContentLoaded', function() {
  const params = new URLSearchParams(window.location.search);
  const campaignSource = params.get('utm_source');

  // If a utm_source exists and we haven't already stored one...
  if (campaignSource && !localStorage.getItem('initial_utm_source')) {
    localStorage.setItem('initial_utm_source', campaignSource);
    localStorage.setItem('first_touch_timestamp', new Date().toISOString());
    // You'd store all the other utm_* params too
  }
});

Then, when a conversion event happens (like a form submission), your code just pulls those values from localStorage and includes them in the data sent to your analytics service. It’s quick, dirty, and it works. Mostly.

Warning: This is a hack, not a solution. It’s entirely dependent on the user’s browser. If they clear their cache, use a different browser, or have privacy settings that block local storage, the data is gone. Use this to buy yourself time, not to build your business on.

Solution 2: The ‘Let’s Do It Right’ Permanent Fix

The real, robust solution is to manage this state on the server side. The client shouldn’t be responsible for remembering its own history. This is where a centralized session store, like Redis, becomes your best friend.

The flow looks like this:

1. User lands on your site from an ad. The web server (e.g., web-app-az1-04) sees the UTM parameters.
2. The server generates a unique session ID, creates a hash in Redis with that ID as the key, and stores all the first-touch data (referrer, campaign ID, timestamp).
3. It sends this session ID back to the user’s browser in a secure, HTTP-only cookie.
4. Now, every subsequent request from that user, no matter which web server it hits, will contain that session cookie. The server can use the ID to instantly look up the full user journey data from Redis.
5. When the conversion happens on web-app-az2-11, it looks up the session ID, finds the original `utm_source`, and correctly attributes the conversion.

# Pseudocode for what your server-side app would do
function handle_initial_request(request):
  session_id = get_or_create_session_id(request)
  
  # Check if first-touch data is already in Redis for this session
  if not redis_client.exists(f"session:{session_id}:first_touch"):
    first_touch_data = {
      "utm_source": request.query_params.get("utm_source"),
      "utm_medium": request.query_params.get("utm_medium"),
      "timestamp": now()
    }
    # Set the data with an expiration (e.g., 30 days)
    redis_client.hmset(f"session:{session_id}:first_touch", first_touch_data)
    redis_client.expire(f"session:{session_id}:first_touch", 2592000)
  
  return response_with_session_cookie(session_id)

This is the industry-standard approach. It’s fast, reliable, and survives browser cache clears. It centralizes the logic and gives you a single source of truth for user session data.

Solution 3: The ‘Never Lose Data Again’ Nuclear Option

For large-scale systems or when *every single interaction* is critical, you might need to go a step further. Instead of just storing the first touch, you can adopt an event-sourcing pattern. Every single user action—a page view, a button click, a form field interaction—is fired off as an immutable event to a message queue like Kafka or AWS Kinesis.

Your web servers become simple event producers. They don’t track state; they just scream into the void: “User XYZ just viewed page ABC with referrer Google!”. Downstream, separate consumer services listen to this firehose of events, piece together the user journeys, and load the structured, attributed data into your analytics warehouse (like prod-analytics-db-01). This decouples your application from your analytics, is incredibly scalable, and allows you to “replay” history if you ever change your attribution logic. It’s overkill for most, but for high-traffic enterprises, it’s the ultimate source of truth.

Comparing The Approaches

The Real Takeaway

That “wrong” marketing data wasn’t a marketing problem. It was an architecture problem. As engineers, our job isn’t just to keep the servers running; it’s to build systems that support the business’s goals. Sometimes that means realizing that a stateless architecture needs a centralized memory. For us, implementing a Redis session store turned that panic-inducing Jira ticket into a case study on how good infrastructure can directly impact the bottom line. So the next time you hear about “bad data,” dig deeper. You might just find a missing piece of your architecture.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions