API i MCP · Przepisy
Analityka, która wchodzi
w pipeline.
Trzy wzorce, które zespoły prowadzą na produkcji: witryna preview per pull request, konwersja testu dymnego po każdym wdrożeniu i nocny pobór uczciwych agregatów do magazynu danych. Wszystkie trzy to te same dwa czasowniki — odczyt ze scope'em, zapis ze scope'em.
- name: Register the preview site run: | curl -X POST "$OBSERVER_URL/api/v1/sites" \ -H "Authorization: Bearer $OBSERVER_KEY" \ -d '{ "name": "pr-'$PR'", "domain": "pr-'$PR'.staging.example.com" }' - name: Record a test conversion run: | curl -X POST "$OBSERVER_URL/api/v1/events" \ -H "Authorization: Bearer $OBSERVER_KEY" \ -d '{ "site": "obs_shop01", "goal_id": "e2e_smoke" }'
Przepis 1 · Środowiska preview
Witryna per pull request.
Programowe tworzenie witryn istnieje dokładnie do tego: POST /api/v1/sites rejestruje środowisko preview z CI i zwraca snippet, zweryfikowany tak, jak weryfikuje go kreator dodawania witryny w dashboardzie. Pull request dostaje własną przestrzeń nazw analityki; scalenie ją rozbiera.
Zablokowany do domeny od urodzenia
Lista dozwolonych witryn nowej witryny wiąże snippet z domeną preview — ten sam kod wklejony gdziekolwiek indziej zostaje odrzucony na collectorze.
Jeden klucz CI, dwa scope'y
write:sites, by zarejestrować środowisko, write:events, by potwierdzić lejek — nic odczytanego, nic więcej zapisanego.
Przepis 2 · Konwersje testu dymnego
Dowód lejka po każdym wdrożeniu.
Drugi krok CI zapisuje zdarzenie po stronie serwera przez POST /api/v1/events — konwersję testu dymnego na celu, który istnieje tylko dla tego. Bo podróżuje ścieżką s2s collectora, testuje cały łańcuch: snippet się ładuje, tracker wysyła beacony, collector przyjmuje, cel się liczy. Lejek jest potwierdzony end-to-end po każdym wdrożeniu, a nie gdy marketer się zorientuje.
Pętlę zamyka alert
Reguła alertów na licznik celu (cele 24 h) pilnuje celu testu dymnego — jeśli pipeline pęknie, alert strzeli, zanim dashboard zacznie kłamać.
Znaczniki wdrożeń dają kontekst
Wyślij webhook wdrożenia, a Overview pokaże delty od ostatniego wdrożenia — konwersja testu dymnego ląduje tuż obok znacznika, do którego należy.
# crontab — 02:00 nightly, read-only key 0 2 * * * curl -s "https://sa.yourdomain.com/api/v1/pages" \ -H "Authorization: Bearer $OBSERVER_KEY_RO" \ | warehouse-loader pages 0 2 * * * curl -s "https://sa.yourdomain.com/api/v1/vitals" \ -H "Authorization: Bearer $OBSERVER_KEY_RO" \ | warehouse-loader vitals
Przepis 3 · Zaplanowany eksport BI
Magazyn danych dostaje uczciwe liczby.
Utwórz klucz tylko do odczytu, scope'owany na dwie witryny, a potem pozwól nocnemu zadaniu pobierać /api/v1/pages i /api/v1/vitals do Twojego magazynu. Odpowiedzi przechodzą ten sam post-filtr k-anonimowości co dashboard — z kwalifikatorami exact, estimated i suppressed nienaruszonymi — więc liczby, które wykreśla Twój BI, to liczby, które pokazuje Twój dashboard. Żadnej równoległej prawdy.
read:reports, dwie witryny, koniec
Klucz BI nie wypisze sesji, nie dotknie rejestru ani niczego nie zapisze — jego lista dozwolonych witryn wymienia dwie witryny, o które raportuje.
Liczniki wywołań trzymają to na widoku
Per-kluczowe limity zapytań i liczniki wywołań oznaczają, że nocne zadanie widać dokładnie takim, jakim jest — jeden klucz, dwa wywołania, co noc.
Twój pipeline,
Twoja analityka.
Witryny preview, konwersje testu dymnego i nocne eksporty — wszystko za kluczami ze scope'ami wydanymi podczas onboardingu.