Peacock

Theme

Personalisation — Audience-Segments + Story-Varianten ​

Peacock liefert pro Seitenaufruf eine Variante, die zur Audience passt — auf Basis von Country, Language, Device, Referrer-Domain und UTM-Quelle. Keine Cookies, keine clientseitige A/B-Testing-Library.

Wie matching funktioniert ​

Beim ersten CDN-Read durchläuft die Story drei Selektoren in dieser Reihenfolge:

  1. Explizites ?segment= — wenn die SDK / der Embed-Script ein Segment forciert, wird genau das verwendet (oder nichts, falls die Variante nicht existiert).
  2. Sticky-Cookie peacock_segment — wenn das Frontend ihn aus einer früheren Auswahl gesetzt hat, gewinnt der Cookie.
  3. Auto-Matching via Headers — die CDN liest:
    • CF-IPCountry (Cloudflare) für country-Rules
    • Accept-Language für language-Rules
    • User-Agent UA-Regex für device-Rules
    • Referer substring-match für referrer_contains-Rules
    • ?utm_source= query oder Cookie für utm_source-Rules

Trifft eine Rule, wird die Variante geladen. Mehrere Segmente? Niedrigste priority gewinnt (Default 100).

Segment anlegen ​

bash
curl -X POST https://peacock-cms.webhoch.com/v1/spaces/<slug>/audience-segments \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "dach-mobile",
    "label": "DACH · Mobile",
    "priority": 10,
    "rules": [
      { "type": "country",  "in": ["AT", "DE", "CH"] },
      { "type": "device",   "is": "mobile" }
    ]
  }'

Oder im Admin: audiences → + Neues Segment.

Rule-Typen ​

typeFeldBeispiel
countryin: ["AT","DE","CH"] oder is: "AT"DACH
languagestarts_with: "de"Alle de-* Locales
deviceis: "mobile" / "tablet" / "desktop"Mobile only
referrer_containsvalue: "linkedin"LinkedIn-Traffic
utm_sourcein: ["newsletter-may","newsletter-april"]E-Mail-Kampagne

Alle Rules eines Segments sind AND-verknüpft. Brauchst du OR, leg mehrere Segmente mit unterschiedlichen keys an und gib ihnen verschiedene Prioritäten.

Variante schreiben ​

Im Story-Editor (Admin): oben auf den Variant-Switcher klicken, das gewünschte Segment auswählen, "Override erstellen" drücken. Editor lädt die Default-Inhalte als Startpunkt; alles, was du änderst, gehört zur Variante. Save schreibt einen separaten story_variants-Eintrag, ohne den Default-Content zu berühren.

Per API:

bash
curl -X PUT https://peacock-cms.webhoch.com/v1/spaces/<slug>/stories/<uuid>/variants/dach-mobile \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "content": {
      "_component": "page",
      "headline": "Willkommen aus Österreich",
      "lead": "Diese Variante sehen nur DACH-Mobile-Visitors."
    }
  }'

Was bei einem Hit zurückkommt ​

jsonc
GET /v1/cdn/<slug>/stories/welcome
// Response:
{
  "data": {
    "uuid": "…",
    "content": { /* die Variante, NICHT der Default */ },
    "meta": {
      "served_segment": "dach-mobile",   // Welche Variante wurde gewählt
      "served_lang": "de-AT",
      "beacon_url": "https://peacock-cms.webhoch.com/v1/cdn/<slug>/_beacon"
    }
  }
}

Frontend-Code muss nichts kennen — die CDN-Response trägt schon den fertigen Variant-Content. Nur meta.served_segment weicht ab; das Frontend kann es für Reporting weitergeben.

Privacy ​

  • Keine Cookies werden vom Server gesetzt (außer dem optionalen peacock_segment für Sticky-Selection — Client-Code kann ihn verweigern; das Auto-Matching arbeitet weiter via Header).
  • CF-IPCountry kommt von Cloudflare, nicht vom Server. nginx strippt den Header an direkten Origin-Hits → kein Spoofing.
  • Analytics-Beacon (POST /v1/cdn/<slug>/_beacon) loggt served_segment als zusätzliche Dimension; alle anderen Garantien (gehashter Visitor, 25h TTL, 30-Tage-Salt-Rotation) gelten.

Siehe auch ​