Feed/DCO: Dynamisk innhold i alle blokktyper

Konsept

Muliggjøre at alle blokktyper (text, graphic, button, osv.) kan hente og vise dynamisk innhold fra eksterne datakilder. Det finnes allerede en form for DCO i slider, men denne er begrenset til slider-konteksten og krever teknisk forståelse. Målet er å gjøre dynamisk innhold tilgjengelig i alle blokktyper, enklere for kreatører og mindre tekniske brukere — uten at det må være i en slider.

Brukeren mapper datafelter til blokkegenskaper via et intuitivt UI, og innholdet populeres automatisk basert på feed-data.

Bruksområder

• Produktfeeds: Vis produktbilder, priser og navn fra en produktkatalog
• Flerspråklig innhold: Bytt tekst og bilder basert på språk/region
• A/B-testing: Kjør varianter av innhold uten å lage nye creatives
• Personalisering: Tilpass innhold basert på brukerdata eller kontekst
• Kampanjeoppdateringer: Oppdater priser, tilbud og bilder uten å redigere creative manuelt
• Bulk-produksjon: Generer hundrevis av varianter fra én template + én datakilde

Teknisk tilnærming

Datakilder

Kilde	Beskrivelse	Kompleksitet
Google Sheets	Enkel integrasjon via Sheets API, lavt oppsett for kunder	Lav
REST API	Egendefinert endepunkt, fleksibelt	Medium
Asset Library	Koble mot eksisterende asset library (allerede i prod)	Medium
Dedikert Feed API	Eget repo/tjeneste for feed-håndtering	Høy

Binding/mapping

Blokkene trenger et nytt lag i konfigurasjonen:

feedBinding: {
  enabled: boolean
  sourceId: string          // referanse til datakilde
  fieldMappings: {
    [blockProperty]: string // f.eks. "text" → "product_name"
  }
  rowSelector: "index" | "random" | "contextual"
  rowIndex?: number
}

Hver blokk-property som støtter feed får et lite ikon i UI-et som lar brukeren velge mellom statisk verdi og feed-binding.

Eget API-repo vs. eksisterende backend

Alternativ	Fordeler	Ulemper
Utvide Application-Backend	Gjenbruke auth, infrastruktur, deployment	Kan bli rotete over tid
Eget Feed API-repo	Rendyrket ansvar, kan skaleres uavhengig	Ekstra infra, deployment, vedlikehold
Asset Library-integrasjon	Allerede i prod, kjent for brukerne	Begrenset til assets, ikke vilkårlig data

Anbefaling: Start med å utvide Application-Backend med et feed-modul. Vurder eget repo når/hvis behovene vokser.

Arkitektur-skisse

┌─────────────┐     ┌──────────────┐     ┌────────────────┐
│ Google Sheet │     │ REST API     │     │ Asset Library   │
│ / CSV        │     │ (kundens)    │     │ (Cavai)         │
└──────┬──────┘     └──────┬───────┘     └───────┬────────┘
       │                   │                     │
       └───────────┬───────┘─────────────────────┘
                   ▼
          ┌────────────────┐
          │  Feed Service  │  (Application-Backend)
          │  - Caching     │
          │  - Validering  │
          │  - Mapping     │
          └───────┬────────┘
                  ▼
          ┌────────────────┐
          │  Creative      │
          │  Config (UI)   │  Feed-binding per blokk
          └───────┬────────┘
                  ▼
          ┌────────────────┐
          │ Creative       │
          │ Engine         │  Renderer med feed-data
          └────────────────┘

Avhengigheter

• Asset Library (i prod) — for å koble feeds til eksisterende assets
• Application-Backend — nytt feed-endepunkt/modul
• Creative-Engine — må støtte dynamisk property-resolving i blokker
• Application-Frontend — feed-binding UI i blokkonfigurasjonen

Kompleksitet

Komponent	Estimat	Kommentar
Feed Service (backend)	Medium	CRUD + caching + kilde-adaptere
Feed-binding UI (frontend)	Medium	Mapping-editor, preview
Engine-integrasjon	Lav–Medium	Property-resolving ved render
Google Sheets-adapter	Lav	Sheets API er velkjent
Asset Library-kobling	Lav	Allerede i prod

Totalt: Medium kompleksitet. Kan MVPes relativt raskt med Google Sheets + text/graphic blocks.

Neste steg

1. Kartlegge hvilke blokk-properties som bør støtte feed-binding først (tekst, bilde-URL, lenke)
2. Prototype feed-binding UI i én blokktype (f.eks. text block)
3. Avklare om Asset Library-API-et allerede eksponerer nok data
4. Vurdere caching-strategi (build-time vs. runtime feed-henting)
5. Diskutere med backend-teamet om feed-modul i Application-Backend