Should you just build attribution yourself?

You can build this. It is not magic, there is no proprietary algorithm, and the data model is four tables. We built it, which is why we can be specific about what it costs.

The weekend version (and it works)

visitors(id, anonymous_id, first_touch_*, last_touch_*, person_id)
events(id, visitor_id, name, source, category, occurred_at, properties)
people(id, email, identified_at, identified_via)
conversions(id, visitor_id, person_id, value_cents, dedup_key, occurred_at)

Plus four pieces of code:

1. A before_action that mints a UUID and sets it in a first-party Set-Cookie — durable, HttpOnly, two years. This single step puts you ahead of most instrumented sites on the internet.
2. UTM and click-id capture on the landing request, written to the visitor as first touch if empty and last touch always.
3. An identify call that binds an email to the visitor when someone signs up or subscribes.
4. A conversion write from your payment webhook.

Two days of work. Genuinely useful. If your business is simple and your team is technical, this may be all you ever need — and you should build it rather than buy anything.

Then the tail

The gap between “it works” and “I would put this in a board deck” is where the estimate goes wrong:

Bots. Crawlers, uptime monitors, link previewers, prefetches, your own team. Your visitor count is wrong by a humiliating margin until this is handled, and you will find out in a meeting.

Turbo, SPAs and prefetch. Client-side navigation is not a document load. Speculative prefetch is not a visit. Both silently corrupt counts in opposite directions.

Redirect chains. UTMs get stripped by shorteners, 301s and consent flows. Capture has to happen on the first landing request or you lose the campaign entirely.

De-duplication. Client and server both report the purchase. Without a shared business key you double count; with a badly chosen key you drop real sales. Then webhooks retry and you need idempotency anyway.

Identity merges. One person, two devices, two anonymous ids, one email — arriving out of order. Merging correctly and idempotently is the single hardest part of the whole system, and it produces subtle wrong-number bugs for months after you think it is done.

Time. Timezones, day boundaries, “last 30 days” meaning three different things to three stakeholders, and the fact that late-arriving server events change yesterday’s totals after you already reported them.

Volume. The events table is the fastest-growing table you own. Indexes, partitioning, and denormalising first-touch onto the visitor so reporting does not need a join.

Reporting. Grouped aggregates, first vs last touch, ad spend joins, CAC and ROAS, and a UI someone will actually open.

The debugging surface. When a number looks wrong — and it will — you need a way to inspect one visitor’s raw event stream. Most homegrown systems skip this, and it is the feature you need most in the exact meeting where the numbers are challenged.

Six to ten weeks of focused engineering, in our experience, plus permanent ownership.

The honest comparison

Build if

• Your data model is genuinely unusual and no product fits it.
• You already have a warehouse and a data team, so this is modelling rather than infrastructure.
• Attribution is close enough to your core product that owning it is strategic.
• You have a specific reason no third party may hold the data.

Buy if

• You want an answer this month rather than next quarter.
• Your engineers have higher-leverage work than bot filtering.
• You want the debugging surface without building it.
• $29 is less than the meeting you had about this.

What we would tell an engineer

Build the two-day version this week regardless. The server-set cookie plus UTM capture plus a conversion write from your webhook is a genuine upgrade over anything client-side, and you will understand the problem far better afterwards.

Then decide whether the remaining ninety percent is your best use of a quarter. Our Rails guide shows exactly how we do it in our own app — including the isolation boundary between the product and the dogfooding, which is the design decision we would most want to keep if we were starting again.