Key takeaways
- We had three referral programs running at once. Only one had ever paid anybody.
- Browser storage cannot cross from a shop subdomain to a main site. They are different origins, so each was blind to the other's referral code.
- A cookie on the parent domain is shared by both. That single change is what made one link work across two separate websites.
- The bug that would have cost real money was a commission rate stored as a decimal and read as a percentage. It pays six dollars on a three thousand dollar deal.
- The second money bug ran the other way: one sale visible in two places pays the same person twice unless the payout job is narrowed on purpose.
We run two websites. The main agency site, and a separate shop on a subdomain that sells our tap to review cards. Different platforms, different code, same business.
And at one point we had three different referral systems layered over them, because each one arrived with a different tool and nobody ever turned the old one off.
Two of the three had never paid a single person
Before consolidating anything, I went and looked at what each one had actually produced. That is worth doing before a rebuild, because the answer changes what you build.
The CRM's built in affiliate tracker only attributes its own order forms and payment links. Our website produces calendar bookings and form submissions, and the tracker structurally cannot credit either one. A live test gave us one click, zero attributed leads, zero dollars. Not broken. Pointed at the wrong thing.
The one we had built ourselves was worse in a funnier way. It had an application form, an approval step, the whole flow. Its list of approved affiliates was empty on the day it shipped and still empty on the day we deleted it. Nobody had ever been approved, because nobody had ever applied, because it was never anybody's job to promote it.
The shop's program was the one that worked. Self serve signup, validated codes, click tracking, automatic commission calculation, payouts, a dashboard. So the decision was not which to build. It was how to make the working one cover both websites.
Why the link kept forgetting on the way across
The shop remembered a referral code using browser storage, which is the normal way to do this. Someone clicks a link with a code in it, the code is saved, and if they buy a week later the code is still there.
But browser storage is scoped per origin, and a subdomain is a different origin from the main site. As far as the browser is concerned those are two unrelated websites that happen to be spelled similarly. So a code saved on the shop was completely invisible to the main site, and the other way around too.
That meant a referral link only worked for whichever half of the business it happened to land on. Send someone to the shop and they buy a website build instead, and the person who referred them gets nothing.
A cookie set on the parent domain is shared across the main site and every subdomain under it. So both sides now write and read the same cookie, ninety days, first touch wins. One link, either address, both properties.
The detail I like about this one: the CRM tracker we retired had been using exactly that technique the whole time. We deleted the program and kept the trick.
The two bugs that would have paid the wrong amount
Both were caught while building, and both would have been quiet.
A rate stored as a decimal, read as a percentage. The commission rate comes back as 0.20, meaning twenty percent. The old code treated it as the number 20 and divided by a hundred, which works out to 0.2 percent. On a three thousand dollar deal that is six dollars instead of six hundred. Nothing errors. The affiliate just gets an insulting cheque and has to be the one who notices.
The same sale visible in two places. Shop orders get commissioned automatically the moment they are paid. They also create a record in a second sales pipeline, carrying the same referral code. The job that pays out agency deals scans pipelines for referral codes, so if you let it scan widely it finds those shop orders too and pays every shop affiliate a second time for a sale that was already settled.
The fix is a deliberately narrow filter: that job looks at exactly one pipeline and nothing else. It is the kind of restriction that looks arbitrary six months later, which is why the reason sits next to it in the code.
A third guard sits under both. Every commission row carries a unique order reference and the database refuses to store the same one twice, so a repeat run fails with a duplicate error and that failure is the success condition. The safest ledger is one where paying twice is impossible rather than merely unlikely.
What marketing automation San Jose businesses can take from this
Plenty of businesses around here end up with a main site and a second address for something, a booking page, a shop, a landing page a marketer built on their own platform. Then they try to run one promotion across all of it and the numbers never quite add up.
Four things worth checking:
- Click your own referral or campaign link, then navigate to the other address. If the tracking does not survive the trip, it is not tracking, it is a guess.
- Count how many attribution systems you are running. Anything in the page header from a tool you no longer use is still collecting and still influencing what you believe.
- Ask what each one has actually paid out. Not what it could do. What it did. Two of ours had paid nothing, ever, and that made the decision easy.
- Check whether a single sale can be counted by two systems. If yes, you are either double paying or double counting, and both are expensive in different ways.
The honest lesson here is not technical. We had three programs because adding one was always easier than auditing the ones we had, which is the default state of every marketing stack I have ever been handed, including our own.
If you want someone to audit your setup, or to build marketing automation San Jose businesses can actually trust across every address they own, that is our work. Have a look at optechsol.llc.