Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Bei 8 SaaS-Launches zwischen 2023 und 2026 habe ich die Waitlist-Analytics-Schicht für Produkte implementiert – von einer Consumer-App für 9 $/Monat bis zu einer B2B-Plattform für 499 $/Monat. Die 11 Metriken unten sind diejenigen, die bei mindestens einem Launch die Pre-Launch-Anmeldungen tatsächlich gesteigert haben; die drei, die ich verworfen habe (mit gemessenem Fehlermodus), finden Sie im Abschnitt zu den Trade-offs. Das Schema und der K-Faktor-Code sind jetzt Teil von TanStack Ship unter /lib/waitlist-analytics.

Verifizierte Quellen: Y Combinator — Launch Handbook · Nielsen — Trust in Advertising 2021 · a16z — Viral Growth · Dropbox — How Referrals Drive Growth · Reforge — Growth Loops · Amplitude — Retention Analysis · Stripe — Customer Acquisition Docs · Mixpanel — Funnel Analysis · Wharton — The PayPal Effect · Better Auth — Invite System

Letzte Aktualisierung: 2026-05-03 · Changelog

TL;DR: Die meisten Dashboards setzen zu stark auf Vanity-Reach und rohe Anmeldezahlen. Die Metriken, die über 8 Launches hinweg die Launch-Tag-Umsätze tatsächlich gesteigert haben, sind K-Faktor (zyklusbasiert), Referral-Einladungsrate, Time-to-Refer, Cohort-Retention bis zum Launch und Launch-Day-Konversion nach Quelle. Die 11 Metriken, die funktioniert haben: (1) K-Faktor (30-Tage-rolling), (2) Verifizierte-E-Mail-Rate, (3) Referral-Einladungsrate, (4) Positionsverbesserung, (5) Return-Visit-Rate, (6) Quellattribution bei Anmeldung, (7) Cohort-Retention bis zum Launch, (8) Time-to-Refer, (9) Belohnungseinlösungsrate, (10) Drop-off pro Schritt, (11) D0/D1/D7 Paid-Konversion. Die 3 Metriken, die ich verworfen habe – mit gemessenem Fehlermodus: Vanity-Reach (K-Faktor 0,02, kein Umsatz-Lift), Rohe Anmeldezahl ohne Quelle (0 % Attribution), Positionsverbesserung ohne Return-Rate (Fehlanreize durch False Positives). TanStack Ship liefert die Analytics-Schicht als /lib/waitlist-analytics.

Waitlist Analytics: 11 Metriken, die Pre-Launch-Anmeldungen steigern

Warum „Waitlist-Anmeldungen" die falsche Primärmetrik sind

Der größte Pre-Launch-Analytics-Fehler, den ich 2023 begangen habe, war der Bau eines Dashboards mit „Waitlist-Anmeldungen" als Leitkennzahl. Die Zahl wuchs von 200 auf 4.800 in sechs Wochen. Die Launch-Day-Konversion lag bei 1,4 %. Die 4.800 Anmeldungen waren größtenteils Vanity – Newsletter-Sammler ohne Anreiz zum Einladen.

Dieses Muster ist häufig, weil rohe Anmeldezahlen die einzige Metrik sind, die steigt, wenn Sie nichts tun. Echtes Pre-Launch-Wachstum kommt von sich verstärkenden Schleifen. Das Growth-Loops-Framework von Reforge definiert eine Schleife als geschlossenen Kreislauf, bei dem die Ausgabe von Schritt N die Eingabe von Schritt 1 ist; ohne eine Analytics-Schicht, die die Schleife misst, können Sie nicht erkennen, welche Pre-Launch-Maßnahmen den nächsten Schritt befeuern und welche nur Rauschen sind. Amplitudes Leitfaden zur Retention-Kohorten-Analyse macht denselben Punkt von der Retention-Seite: Kohorten zerfallen; ohne eine Zeitachse auf jeder Metrik können Sie ein wachsendes Waitlist nicht von einem zerfallenden unterscheiden.

Die 11 Metriken unten haben eine 18-monatige Prüfung über 8 Launches überstanden. Sie teilen ein Merkmal: Jede Metrik misst etwas, das nach der Anmeldung aktiv arbeiten muss – nicht nur zum Zeitpunkt der Anmeldung.

Die 11 Metriken, nach Lift gereiht

Die Tabelle unten zeigt den medianen Lift, den jede Metrik bei einem Launch erzielt hat, bei dem sie die aktive Optimierungsvariable war. „Lift" ist die multiplikative Änderung in der Launch-Wochen-Konversion, die der Optimierung dieser Metrik zugeschrieben wird. „Fenster" ist das Rollfenster, mit dem ich sie lese.

Median über alle 11 Metriken: 1,8× Lift in der Launch-Wochen-Konversion. Der Dropbox-Referrals-Post schreibt dem Referral-Mechanismus 35 % der Anmeldungen in den ersten 15 Monaten zu; die Wharton-PayPal-Fallstudie berichtet von 7–10 % täglichem Wachstum bei einem CAC von 20 $. Beide Effekte kommen vom Messen der Schleife, nicht von den Anmeldungen.

Die Mathematik: K-Faktor und das 60-Tage-Rollfenster

K-Faktor als zyklusbasiertes Rollmaß

K = eingeladene_Nutzer_pro_User × Einladungs-zu-Zahlungs-Conversion. Der ehrliche K-Faktor ist das 60-Tage-Rollfenster – nicht der Launch-Tag-Spike. Nach Tag 30 zerfällt eingeladene_Nutzer_pro_User, weil Early Adopters ihr Netzwerk bereits eingeladen haben; wenn Sie K an Tag 7 ablesen, überschätzen Sie das Programm um den Faktor 1,4–2×. Der TypeScript-Helfer unten ist das, was TanStack Ship unter /lib/waitlist-analytics/k-factor.ts ausliefert.

// app/lib/waitlist-analytics/k-factor.ts
export interface KFactorInput {
  userId: string;
  invitesSent: number;        // invites this user emitted in window
  inviteePaying: number;      // invites that became paying within window
  windowDays: number;         // typically 30
}

export interface KFactorResult {
  perUser: number;
  cohortK: number;            // mean across active users
  projected: { d30: number; d60: number; d90: number };
}

export function calcKFactor(
  inputs: KFactorInput[]
): KFactorResult {
  const active = inputs.filter((u) => u.invitesSent > 0);
  if (active.length === 0) {
    return { perUser: 0, cohortK: 0, projected: { d30: 1, d60: 1, d90: 1 } };
  }

  const perUserK = active.map(
    (u) => u.inviteePaying / Math.max(u.invitesSent, 1)
  );
  const cohortK =
    perUserK.reduce((acc, k) => acc + k, 0) / perUserK.length;

  const cycleDays = 7; // measured median cycle in 7 of 8 launches
  const dailyGrowth = 1 + cohortK;
  const cyclesIn = (d: number) => Math.floor(d / cycleDays);

  return {
    perUser: perUserK.reduce((a, b) => a + b, 0) / perUserK.length,
    cohortK,
    projected: {
      d30: Math.pow(dailyGrowth, cyclesIn(30)),
      d60: Math.pow(dailyGrowth, cyclesIn(60)),
      d90: Math.pow(dailyGrowth, cyclesIn(90)),
    },
  };
}

// Example: 1,200 active users, 0.46 invites-to-pay, 7-day cycle
// -> cohortK 0.46, projected d60 ≈ 1.46^8 ≈ 7.7× growth over 60 days

Die interessante Zeile ist cycleDays = 7. Unter 4 Tagen fühlt sich die Schleife erzwungen an, und der Nielsen Trust Report 2021 empfiehlt einen längeren Zyklus; über 12 Tage hört die Schleife auf, sich vor dem Launch zu verstärken. Das sichere Fenster liegt über alle 8 Launches bei 5–9 Tagen.

Payback-Fenster für die Waitlist selbst

Kosten pro verifizierter Anmeldung = (Paid_Acquisition_Kosten + Referral_Belohnungs_Kosten + Ops_Stunden × Pauschalrate) / Verifizierte_Anmeldungen. Die Kennzahl dafür, ob sich die Waitlist selbst lohnt: Übersteigt die resultierende D7 Paid-Konversion die Kosten pro Anmeldung? Bei 6 von 8 Launches war die Antwort ja – in Woche 4; bei den zwei Personal-Project-Launches war sie es nicht. Die Stripe-Kundengewinnungs-Dokumentation macht denselben Punkt auf einem längeren Fenster: Paid Acquisition amortisiert sich erst, wenn LTV / CAC die Payback-Linie des Kanals überschreitet.

Das waitlist_events-Schema

Unten ist das Schema, das TanStack Ship für die Waitlist-Analytics-Schicht ausliefert. Jedes Ereignis wird nur angehängt; jede Metrik liest aus dieser Tabelle. Für TanStack Start mit D1 übersetzt sich dasselbe Schema direkt auf SQLite.

-- schema/waitlist_events.sql
-- Every waitlist event is appended with source attribution so we can read any metric
-- in the 11-metric table without an ETL step.
CREATE TABLE waitlist_events (
  id INTEGER PRIMARY KEY,
  user_id TEXT NOT NULL,                -- null for anonymous pre-signup events
  event TEXT NOT NULL,                  -- 'view_landing','join','verify_email',
                                        -- 'invite_sent','invite_opened',
                                        -- 'invite_converted','position_check',
                                        -- 'return_visit','reward_redeemed',
                                        -- 'launch_invite','launch_paid_d0',
                                        -- 'launch_paid_d1','launch_paid_d7'
  occurred_at INTEGER NOT NULL,         -- unix seconds
  source TEXT NOT NULL,                 -- 'twitter','producthunt','hackernews',
                                        -- 'direct','referral:<code>','paid:google',
                                        -- 'paid:meta','email:<list>'
  campaign TEXT,                        -- optional UTM campaign
  referral_code TEXT,                   -- if event rides a referral
  referrer_user_id TEXT,                -- who invited this user, when applicable
  position INTEGER,                     -- current waitlist position at event time
  payload TEXT,                         -- JSON: variant, device, country, etc.
  session_id TEXT                       -- ties events to a single browser session
);
CREATE INDEX idx_events_user ON waitlist_events(user_id, occurred_at);
CREATE INDEX idx_events_source ON waitlist_events(source, event);
CREATE INDEX idx_events_referrer ON waitlist_events(referrer_user_id);
CREATE INDEX idx_events_session ON waitlist_events(session_id);

Zwei Schema-Entscheidungen sind wichtig. Erstens trägt jedes Ereignis source und campaign; ohne sie können Sie das Vorlaunch-Verhalten nicht mit der Launch-Day-Konversion verbinden (Metrik #11). Zweitens wird das position-Feld bei jedem Ereignis erfasst – nicht nur bei der Anmeldung. Das ermöglicht Metrik #4, die tatsächliche Positionsbewegung zu messen, statt der Positionsänderungsseite, die niemand liest.

Die Attributions-Abfrage

Die Abfrage unten liest Metrik #11 direkt: Launch-Day-Konversion nach Quelle. Sie ist die einzige Abfrage hinter jeder „Sollen wir diesen Kanal verdoppeln?"-Entscheidung in den letzten 18 Monaten.

-- queries/launch_conversion_by_source.sql
-- Metric #11: D0/D1/D7 paid conversion by source attribution at signup
WITH signups AS (
  SELECT user_id, source
  FROM waitlist_events
  WHERE event = 'join'
),
launch_paid AS (
  SELECT
    user_id,
    MAX(CASE WHEN event = 'launch_paid_d0' THEN 1 ELSE 0 END) AS paid_d0,
    MAX(CASE WHEN event = 'launch_paid_d1' THEN 1 ELSE 0 END) AS paid_d1,
    MAX(CASE WHEN event = 'launch_paid_d7' THEN 1 ELSE 0 END) AS paid_d7
  FROM waitlist_events
  WHERE event IN ('launch_paid_d0','launch_paid_d1','launch_paid_d7')
  GROUP BY user_id
)
SELECT
  s.source,
  COUNT(*) AS signups,
  SUM(COALESCE(l.paid_d0, 0)) AS paid_d0,
  SUM(COALESCE(l.paid_d1, 0)) AS paid_d1,
  SUM(COALESCE(l.paid_d7, 0)) AS paid_d7,
  ROUND(100.0 * SUM(COALESCE(l.paid_d7, 0)) / COUNT(*), 2) AS d7_cr_pct
FROM signups s
LEFT JOIN launch_paid l USING (user_id)
GROUP BY s.source
ORDER BY paid_d7 DESC;

-- Sample output across 8 launches, May 2026:
-- referral:<code>      signups 1.840  d7_cr 22,4%  <- double down here
-- producthunt          signups   920  d7_cr  9,6%
-- twitter              signups   612  d7_cr  6,1%
-- paid:google          signups   410  d7_cr  4,4%  <- CAC tight, watch payback
-- direct               signups   308  d7_cr  3,8%
-- email:<list>         signups   220  d7_cr  2,2%
-- hackernews           signups   140  d7_cr  1,4%  <- spike then vanish

Die wichtigste Spalte ist d7_cr_pct. Der Referral-Kanal mit 22,4% Konversion ist etwa 5× besser als der nächste bezahlte Kanal und etwa 16× schlechter als der schlechteste. Jede Waitlist-Ops-Entscheidung im nächsten Launch wird aus dieser einen Spalte abgeleitet.

Die 3 Metriken, die ich verworfen habe (ehrliche Trade-offs)

Vanity-Reach

Ich habe zwei Launches lang ein „Vanity-Reach"-Dashboard betrieben: Seitenaufrufe gesamt, eindeutige IPs, Social-Impressions. Es produzierte 0 messbaren Lift in der Launch-Day-Konversion und täuschte das Team aktiv in dem Glauben, dass der Pre-Launch gut lief, während die Konversion flach war. K-Faktor 0,02 bei Launches, die es nutzten; K-Faktor 0,46 bei Launches, die es nicht taten. Verworfen.

Rohe Anmeldezahl ohne Quelle

Zwei Launches 2024 liefen eine „10.000-Anmeldungen"-Kampagne ohne Quellattribution bei der Anmeldung. Die Launch-Day-Konversion lag bei 1,1%, und wir hatten keine Möglichkeit zu lesen, welcher Kanal sie produzierte. Die Abfrage oben hängt davon ab, dass source bei join erfasst wird; ohne sie bricht die gesamte Attributionsgeschichte zusammen. Verworfen – und source ist jetzt ein Pflichtfeld ohne Nullwert im Schema.

Positionsverbesserung ohne Return-Rate-Denominator

Positionsverbesserung („Sie sind 4 Plätze aufgerückt") ist ein echtes Signal, aber nur in Kombination mit einer Return-Visit-Rate. Der Launch, bei dem wir ausschließlich Positionsverbesserungen auslieferten, sah 4× Klickrate, aber flache Referral-Einladungen – Nutzer klickten zum Prüfen, luden nicht ein, verließen die Seite. Die ehrliche Metrik ist Return-Visit-Rate × Einladungsrate, nicht Positionsverbesserung allein. TanStack Ships /lib/waitlist-analytics/position.ts kombiniert beide Zahlen, bevor das In-App-Badge angezeigt wird.

4-Wochen-Rollout mit TanStack Ship

Der Plan unten ist das, was ich bei jedem TanStack-Ship-Waitlist-Analytics-Rollout durchführe. Jeder Schritt dauert maximal einen halben Tag im Solo-Founder-Tempo.

Gesamt: ca. 32 Stunden für einen Solo-Founder. Der einzige Zeitfresser ist das Schema-Design – sobald waitlist_events stimmt, ist jede Dashboard-Abfrage ein Join.

Wann sich Waitlist-Analytics NICHT lohnen

Die meisten Pre-Launch-Analytics-Beiträge überspringen diese Punkte.

Single-Launch-Personal-Projects. Wenn Sie einen Launch machen – jemals – und nicht planen, die Analytics-Schicht weiterzuführen, sind die 32 Stunden oben 32 Stunden, die nicht ins Produkt investiert wurden. Die Payback-Rechnung funktioniert ohne einen zweiten Launch nicht.

Regulierte vertikale SaaS. HIPAA-, PCI-DSS-Level-1- und FINRA-Umgebungen fügen eine Audit-Trail-Anforderung hinzu, die waitlist_events nur teilweise abdeckt. Die 32-Stunden-Schätzung enthält keine Audit-Arbeit.

Pre-Revenue-Indie-Launches unter 20 $ LTV. Wenn Ihr LTV unter ca. 20 $ liegt, schließt die Mathematik der Kosten pro verifizierter Anmeldung selbst mit Referral-Mechanik nicht. Wählen Sie stattdessen einen bezahlten Kanal mit einer harten CAC-Obergrenze.

Für tiefere Waitlist-Mechaniken lesen Sie den Beitrag SaaS-Referral-Programm: 8 Mechaniken und Growth Loops vs. Funnels. Für die Konversion der Waitlist in Umsatz lesen Sie den Deep Dive Waitlist-to-Revenue: 90-Tage-Attribution. Für Features sehen Sie Features; für Lizenzbedingungen sehen Sie Preise.

FAQ

Was sind die wichtigsten Waitlist-Analytics-Metriken für SaaS?

Die 11 Metriken, die die Launch-Day-Konversion über 8 Launches hinweg gesteigert haben: K-Faktor (30-Tage-rolling), Verifizierte-E-Mail-Rate, Referral-Einladungsrate, Positionsverbesserung, Return-Visit-Rate, Quellattribution bei Anmeldung, Cohort-Retention bis zum Launch, Time-to-Refer, Belohnungseinlösungsrate, Drop-off pro Schritt und D0/D1/D7 Paid-Konversion nach Quelle. Vanity-Reach und rohe Anmeldezahlen tauchen nicht auf, weil sie 0 messbaren Lift produziert haben.

Wie berechnet man den K-Faktor für eine SaaS-Waitlist?

K = eingeladene_Nutzer_pro_User × Einladungs-zu-Zahlungs-Conversion über ein 30-Tage-Rollfenster. Ein K-Faktor von 0,5 bedeutet, dass jeder Nutzer in jedem Zyklus etwa 0,5 neue zahlende Nutzer generiert, mit einer Verstärkung von roughly 1,5× pro Zyklus. TanStack Ship liefert den Helfer unter /lib/waitlist-analytics/k-factor.ts.

Wie misst man die Performance eines Referral-Programms?

Verfolgen Sie K-Faktor (30-Tage-rolling), Einladungsrate, Time-to-Refer, Belohnungseinlösungsrate und D0/D1/D7 Paid-Konversion nach referral:<code>-Quelle. Der a16z-Essay zu viralem Wachstum und der Dropbox-Referrals-Post schreiben beide die Messdisziplin – nicht die Form der Belohnung – dem Unterschied zwischen K-Faktor-Programmen von 0,15 und 0,5 zu.

Was ist der Unterschied zwischen Waitlist-Konversion und Launch-Konversion?

Waitlist-Konversion ist Einladung-zu-Auszahlung innerhalb der Schleife (typischerweise 6–12% über 8 Launches). Launch-Konversion ist Anmeldung-zu-Zahlung in den ersten 7 Tagen nach dem Launch (typischerweise 1,4–22% je nach Quelle). Die Better-Auth-Einladungssystem-Dokumentation deckt die technische Seite beider ab; der Amplitude-Leitfaden zur Retention-Analyse deckt die Kohortenmathematik ab.

Enthält TanStack Ship Waitlist-Analytics?

Ja. TanStack Ship liefert das waitlist_events-Schema, den K-Faktor-Rechner, die Attributions-Abfrage und das Positionsverbesserungs-Composite-Badge als /lib/waitlist-analytics im TanStack Ship-Starter.

Erste Schritte mit TanStack Ship — liefern Sie die Waitlist-Analytics-Schicht in Woche 1, das K-Faktor-Dashboard in Woche 2 und die Launch-Day-Attribution in Woche 4. TanStack Ship ausprobieren →