Veikt izaugsmes eksperimentu ar pārtraukšanas noteikumu

Kad izmantot

The company wants to know whether a specific change improves a number, and is willing to accept "no" as an answer. Not for a one-off campaign or content push — use growth.social-post-weekly or growth.newsletter. Not for an analytics setup itself — use tech.install-analytics first; an experiment without working tracking is not run at all. If the idea came from a competitor scan, start from growth.competitor-scan output, but this playbook still applies.

Pirms sāc

• The primary metric is named and its current baseline is read from site-analytics (not from memory).
• Tracking for that metric already works — an event or pageview exists and fires today.
• Someone can change the site or channel (the agent prepares, a person or agent with deploy access ships).
• If the experiment touches prices, terms or personal data handling, flag it in S3 — that may need a

Ko izpilde pieprasa3

Ceļš9 soļi

1. S1

   Frame the problemaģents

   Write one sentence: what is observed, where, and what the change would be. Note anything that could confound it (a campaign, a season, a price change in the same period).

   Izdarīts, kad the sentence and the confound list exist in the experiment record.

2. S2

   Write the hypothesis and the stop ruleaģents

   Format: "If we <change>, then <metric> moves from <baseline> to <target>, measured over <at least N weeks or M observations>." Write the stop rule: the date or volume at which the test ends no matter what the interim numbers look like, and the rule for stopping early only if the variant is clearly hurting (state the threshold now).

   Izdarīts, kad hypothesis, metric, baseline, end date and stop rule are all written down.

3. S3

   Approve the hypothesisīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S3 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Show hypothesis, metric, baseline, cost of running it (time, any spend), and what happens if it loses.

   Izdarīts, kad the owner has approved or amended the hypothesis, and the end date is fixed.

4. S4

   Check the test can actually concludeaģents

   From site-analytics, estimate how many observations per week the page or channel gets. If the volume cannot plausibly reach a readable difference within 4–6 weeks, say so and propose a bigger change or a different page — do not launch a test that cannot end in a decision.

   Izdarīts, kad the record states the expected observations and the agent's verdict: runnable / not runnable.

5. S5

   Instrument and verify tracking BEFORE launchaģents

   Add or confirm the events in site-analytics for both control and variant. Trigger each event yourself and read it back in the reports.

   Izdarīts, kad every event the hypothesis needs fires and appears in the analytics within minutes.

   ⛔ A test launched on unverified tracking is void — restart the clock after the fix.

6. S6

   Launchaģentsvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Ship the variant (site change, ad variant, copy) with the split as even as the tooling allows. Record the exact launch time — it starts the clock on the stop rule.

   Izdarīts, kad the variant is live and the launch time is in the record.

7. S7

   Monitor, do not peek-decideaģents

   Check weekly that both variants receive traffic and events and that tracking is still firing. Do not call a winner mid-run; the stop rule from S2 governs.

   Izdarīts, kad each weekly check is logged with traffic counts per variant and a one-line "tracking OK / broken".

8. S8

   Close and analyseaģents

   At the end date, pull the numbers for both variants: primary metric, plus any secondary metric already named in S2 (never invented after seeing the data). State the difference plainly and whether it meets the target from S2.

   Izdarīts, kad the result — including "no difference" — is written in the experiment record.

9. S9

   Decide, then actīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S9 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present the result with a recommendation: adopt the variant, reject it, or rerun with a change (and why). The decision is executed the same week — winner shipped, loser removed — and linked via bc tasks add or bc goals add to the goal it serves.

   Izdarīts, kad the site or channel matches the decision, and the record shows the decision, who made it, and when.

Pārbaudes — kā zinām, ka izdevās

• The record contains a baseline read before launch, not after.
• The end date in S2 and the launch time in S6 give a test length that matches the S4 estimate.
• Both variants received traffic every week of the run (no variant silently at zero).
• The result names the primary metric and the end date — a result without an end date is not a result.
• The site after S9 matches the decision, whichever way it went.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the sentence and the confound list exist in the experiment record.
2. S2hypothesis, metric, baseline, end date and stop rule are all written down.
3. S3the owner has approved or amended the hypothesis, and the end date is fixed.
4. S4the record states the expected observations and the agent's verdict: runnable / not runnable.
5. S5every event the hypothesis needs fires and appears in the analytics within minutes.
6. S6the variant is live and the launch time is in the record.
7. S7each weekly check is logged with traffic counts per variant and a one-line "tracking OK / broken".
8. S8the result — including "no difference" — is written in the experiment record.
9. S9the site or channel matches the decision, and the record shows the decision, who made it, and when.

Ko saglabāt

The experiment record: hypothesis, baseline, stop rule, launch time · weekly monitoring log · final numbers per variant with the pull date · the S9 decision and who made it · links to the task/goal and, if adopted, to the change that shipped.

Kā šī procedūra uzlabojas

After every 5 finished experiments ask: how many ended in a written decision vs quietly abandoned? How many results were "no difference", and did those pages get bigger changes proposed? Did any test run past its end date, and which step let it slip? Did any launch ship with unverified tracking? A new version changes the step that let the slip happen, and says so in its change note.