Skip to content

Count a board choice once, and send buying to the account site - #62

Draft
cyberb wants to merge 3 commits into
masterfrom
buy-link-and-board-once
Draft

Count a board choice once, and send buying to the account site#62
cyberb wants to merge 3 commits into
masterfrom
buy-link-and-board-once

Conversation

@cyberb

@cyberb cyberb commented Aug 31, 2026

Copy link
Copy Markdown
Member

Do not merge until the shop page is live on the account site — the buy button points at /shop, which only exists on the redirect branch so far.

setup.board counted every click. Someone comparing three boards counted three times, so the step already exceeded setup.build on live traffic and the monotonicity rule fired on ordinary browsing. It now counts the first choice of a visit, so the number means how many people got as far as choosing.

Buying pointed at the separate shop site. It now points at the shop page on the account site and carries the click id, the same way the download link does — so an ad visitor who buys is connected to that ad rather than disappearing into a second site that knows nothing about them.

The board test fails without the fix rather than passing regardless: it picks three boards and asserts exactly one setup.board went out. 63 tests, lint and build clean.

cyberb added 3 commits August 31, 2026 10:40
setup.board fired on every board button, so somebody comparing three boards
counted three times and the step already exceeded setup.build on live traffic.
It is not a step in a funnel, it is a click, and reading it as a step made the
one rule worth watching -- that a later step cannot exceed an earlier one --
fire on ordinary browsing. It counts the first choice of a visit now, so the
number means how many people got as far as choosing.

Buying pointed at the separate shop. It points at the device page on the account
site, and carries the click id the way the download link already does, so
somebody who arrives from an advert and buys is connected to that advert instead
of vanishing into a second site that knows nothing about them.

The board test fails without the fix rather than passing regardless: it picks
three boards and asserts exactly one setup.board went out.
The account site's buy page is /shop rather than /device, so it can hold more
than one device without moving again.
Every link to the account service was the production address written into the
page, so uat linked to production and testing an interaction meant leaving the
environment under test. The shop link made that worse: from uat it would have
sent a tester to the real shop with a real payment behind it.

The api serves the address at /api/config and the page reads it once at startup.
It is a flag with no default, required like the others, and set per environment:
the test host for the test env, syncloud.info for uat, syncloud.it for prod.
Deploy prepare writes it into an env file the unit reads, so deploy.sh installs
whatever it was given and stays identical everywhere.

The prose that mentions syncloud.it in the faq and the privacy policy is left
alone. It describes the real service and should say so wherever it is read.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant