Republiken · Mötesprep

Vroff: tracking steg 1

Synk med Marcus Gåhlin för att gå från förslag till exakt vad som ska byggas. Målet: flytta konverteringen från klick till faktisk signup och aktivering, utan att röra själva arbetsytan. Hela flödet är redan kartlagt live.

Idag 09:00 · Vroff-möte Jonatan · Marcus Gåhlin (dev, TellusTalk) · Gustav Estimat 8–20h
1

Nuläge

Verifierat live via Claude in Chrome.

  • app.vroff.com är en React-SPA. Login på /dashboard/auth/login, registrering på /dashboard/auth/register, inloggad arbetsyta på /meeting.
  • Noll tracking på appen. Ingen GTM, ingen dataLayer, ingen pixel. Marknadssajten (www, byggd på Storyblok) har allt: GTM, GA4, Google Ads, Meta, Reddit, LinkedIn, Plausible, consent via CookieYes.
  • Signup via OAuth + e-post: Google, Microsoft, e-post. Ett nytt konto kan skapas från både login- och register-sidan.
  • Konverteringen idag är klicket vidare till app. Vi ser vem som tar sig till signup, inte vem som fullföljer.
2

Kärnan: varför det krävs ett backend-event

✓ Verifierat: ingen genväg finns

Jag testade alla klientsidiga vägar att skilja en signup från en inloggning. from-parametern speglar bara startsidan (from=login vs from=register), inte om kontot är nytt. /api/dashboard/user ger bara namn och e-post, ingen createdAt. /api/dashboard/user/exists ger true i efterhand. Slutsats: det enda pålitliga är att appen skjuter ett event i ögonblicket kontoraden skapas i backend.

SPA betyder ingen tack-sida att trigga på

Eftersom appen är en SPA finns ingen sidladdning vid signup. Mätpunkten måste komma som en dataLayer-händelse från appen, inte en URL-trigger. Det är den enda riktiga kodändringen, och den avgör om jobbet landar på 8 eller 20 timmar.

3

Funnel, live-kartlagd

Hela kedjan ligger i Tier 1 och 2, ingenting rör arbetsytan. Det här är motsvarigheten till Safari-dashboarden fast för Vroff: du ser hur långt ner varje kanal faktiskt tar folk, inte bara klickpris.

Når auth-sidanTier 1
Klick in på /login eller /register
Konto skapatBackend-event
account_created · ingen klientsignal, måste komma från backend
Kontor skapatTier 2
Aktivering · POST /api/dashboard/office
Inbjudningar skickadeTier 2
Nätverkseffekt · POST /api/dashboard/office/send_invitation_emails
Medlemmar accepterarTier 2
Traction · PUT /api/dashboard/office/update_members_invite_status
In i arbetsytanTier 3 · mäts ej
POST /api/dashboard/office/enter/meeting. Hård vägg.
4

Hur djupt: tre tiers

Det här är beslutet att lägga fram på mötet, och mot Peder. Vi rekommenderar Tier 2.

1

Bara publika auth-sidor

GTM på /login och /register. Mäter att man tar sig till signup, men missar det faktiska skapandet eftersom det sker efter auth.

2

Auth + /dashboard-skalet Rekommenderas

Här ligger de signaler som är värda något: account_created, office_created, invites_sent. Det är kontots admin- och onboarding-skal, inte produkten. Ger hela aktiveringsfunneln.

3

Inne i arbetsytan (/meeting)

Aldrig. Där lever samtal, möten och innehåll. Det är den linjen som skyddar hela integritets-löftet, och den vi pekar på mot kunden.

Villkor om vi går Tier 2

Bara strukturella event (account_created, office_created, invites_sent), inga automatiska pageviews, inga kontorsnamn eller medlemslistor, ingen persondata i eventen. /api/dashboard/user innehåller e-post, så pixlar får aldrig skicka med den. Annonstaggarna förblir consent-gatade och fyrar bara på konverteringen.

5

Det vi ber Marcus om

Tre dataLayer-event. Konkret kodbegäran, inte en utredning.

Kritisk
account_created
Skjuts där kontoraden skapas i backend. Den enda utan klientsignal, och hela poängen med mötet.
office_created
På lyckad POST /api/dashboard/office. Aktiveringsmåttet.
invites_sent { count }
POST /api/dashboard/office/send_invitation_emails. Antalet inbjudna är nätverkseffekt-signalen.

De tre sista stegen har observerbara XHR-anrop, så GTM kan i nödfall lyssna direkt på dem. Men dataLayer-event från appen är det rena och robusta sättet.

6

Discovery, med svaren ifyllda

Q1, Q2, Q4 och Q5 är verifierade live. Q3 är avgjord i princip, kvar är bara att Marcus exponerar signalen.

Q1Är auth-sidorna samma React-bundle som inloggat läge? Kan vi ladda GTM bara på auth?Nästan klar
Vad vi hittat + hur Marcus bekräftar
✓ Verifierat

/vroff/index.html svarar 401 utan inloggning. Inloggat läge är serverskyddat och separerat. Att isolera GTM till auth + dashboard-skalet är fullt görbart. Kvar: bekräfta exakt injektionspunkt med Marcus.

Marcus kollar i kodbasen om /dashboard/auth/* och arbetsytan byggs från samma entrypoint, och var snippet kan ligga utan att följa med in i /meeting.

Q2Cookies på root .vroff.com eller host-only?Klar
Vad vi hittat
✓ Verifierat, ingen fix behövs

_ga, _fbp och _gcl är läsbara på app trots att appen saknar egen tracking. De är root-scopade på .vroff.com, så attributionen följer med från www automatiskt. Ingen cross-domain-linker krävs.

Q3Vet appen om OAuth blev nytt konto eller inloggning?Kräver Marcus
Vad vi hittat + vad som krävs
Avgjord i princip, behöver dev

Testat: ett nytt konto via Google från login-sidan landar på /dashboard?from=login, alltså går det inte att skilja från en vanlig inloggning på klientsidan. Backend måste skjuta account_created vid kontoradens skapande. Det är den enda kvarvarande dev-beroende biten.

Marcus kollar auth-callbacken/handlern: var skapas user-raden, och kan ett dataLayer-event fyras exakt där?

Q4Finns ett distinkt success-läge efter signup?Klar
Vad vi hittat
✓ Verifierat live

Ja. Nya konton landar i onboarding "Skapa ditt första kontor", och /api/dashboard/office är tom tills kontoret skapas. Skapandet går via POST /api/dashboard/office, följt av invite-anropen. Hela funneln i sektion 3 är kartlagd från en verklig registrering.

Q5Finns CSP-headers som blockar GTM eller pixlar?Klar
Vad vi hittat
✓ Verifierat, ingen blockerare

Auth-sidan skickar ingen Content-Security-Policy alls (ingen script-src, ingen report-only, ingen X-Frame-Options). Inget hindrar GTM eller pixlar.

7

Vem gör vad

Marcus / dev

  • GTM-snippet (GTM-W8R548R9) på auth-sidorna + /dashboard-skalet. Inget i /meeting.
  • Fyra account_created där user-raden skapas i backend.
  • Fyra office_created och invites_sent (med antal).
  • Bekräfta att consent delas över subdomäner, eller lägg CookieYes på auth-sidan.

Republiken

  • All GTM-konfig: triggers på de tre eventen, taggar för GA4, Google Ads, Meta, Reddit, LinkedIn. Consent-gatat.
  • Skapa konverteringspunkterna i annonskontona.
  • QA i GTM preview, verifiera att konverteringarna registrerar.
  • Dokumentation och överlämning.
8

Access att be om

9

Viktigaste utfallet

Lämna inte mötet utan detta

Att Marcus committar till att fyra account_created där kontoraden skapas, plus en grov tidsplan. Det är den enda dev-beroende biten, allt annat är kartlagt och rutin. office_created och invites_sent är bonus som ger hela funneln. Kan han deploya snabbt landar vi i underkant av estimatet.

10

Referens · befintliga ID:n

GTM-containerGTM-W8R548R9
GA4G-9HQ7NT54DW
Google AdsAW-17741655930
Meta-pixel1400976038035718
CMPCookieYes
App-stackReact-SPA