- Shipped
- August 20, 2026 at 1:24 AM UTC
- Author
- Kamo
- Commit
- 6db507c
A member mints a code, shares **************** and the six totals on the Tracking Codes tab answer what that link actually did: unique visitors, visits, page requests, signups, organizations created and paid accounts. Four tables carry it. MARKETING_TRACKING_CODES stores the code string itself rather than recomputing it from memberId and iteration, so the public ingest path is one unique-index probe with no parsing and a malformed ?mrt= is a miss instead of a NumberFormatException. MARKETING_VISITORS is the identity spine, one row per cookie GUID, and its attributed code is written once and never moved: with first-touch attribution the three conversion counters cannot double-count a visitor who later arrives on a second code. MARKETING_VISITOR_CODES is the visitor x code link and the authority for the traffic counters, and MARKETING_VISIT_EVENTS is the append-only timeline the visitor drawer reads. The counters are maintained, not derived, because the grid renders six of them per row and six COUNT(DISTINCT) aggregates over an append-only table on a row store is a scan per page load. What makes that safe is that every bump is an atomic SET x = x + 1 rather than a read-modify-write, and every conversion stamp is a conditional UPDATE gated on IS NULL so a redelivered NATS message updates zero rows — the rowcount is the dedupe. Both "first time seen" tests are native INSERT ... ON CONFLICT DO NOTHING for the same reason. The obvious alternative, catching the unique violation and re-reading, cannot work here: on YugabyteDB the violation aborts the whole transaction (25P02) and Spring marks it rollback-only, so a lost race would drop the entire beacon — the event row, the visitor row and every counter with it. Rights: 154/155 keep their constant names and are only relabelled to "View" and "Manage Tracking Codes", because rights travel by name in the session token and a rename would strip them from every live session with no compile error. Ids 200 and 201 are new and gate cross-member visibility. Neither is seeded into NEW_RIGHT_SEEDS: before this feature nobody could see another member's visitor analytics at all, so seeding from VIEW_REFERRAL_CODES would hand every existing holder a capability they never had.