Om ert Braze-team skriver varje tänkbar datapunkt till användarprofiler kan det vara dags att tänka om.
Inte för att det är fel att skriva attribut till användare - det skulle vara löjligt. Men det finns data som aldrig borde leva i en Braze-profil, och de flesta team gör det ändå för att de inte vet att det finns ett alternativ.
Det alternativet är ‘zero-copy personalization’. Jag kommer att förklara vad det är, när man ska använda det och vad som faktiskt förändras i hur ert team arbetar när ni gör det.
Exempel på en user profile i Braze. (Braze, 2026)
I Braze ser det oftast ut så här: data synkas från ert warehouse till användarprofiler som attribut, det används sedan för segmentering och personalisering. För många use cases är det rätt.
Problemet är att vissa team reflexmässigt skriver allt till användarprofiler, även för data som är:
Tillfällig. Varukorgar, aktuella priser, lagerstatus - allt det här kan ändras mellan synken och utskicket. En sync som körde för 20 minuter sedan är inte samma sak som vad som nu är live i ert warehouse.
Känslig. Finansiella uppgifter, hälsorelaterade attribut eller annan känslig eller begränsad data skrivs till användares profiler fast de bara kanske behövdes för ett enda utskick.
Dyr. Nästan varje attribut som skrivs till en Braze-profil förbrukar Data Points. Vid personalisering i stor skala med många fält per användare blir det snabbt dyrt.
Svår att rensa bort. Efter ett tag samlar användarprofilerna på sig mer och mer data, och att rensa bort gamla attribut hamnar ofta mellan stolarna.
Resultatet är grovt övergödda profiler och ett Braze workspace som innehåller mer än det behöver. Det blir delvis inaktuellt och kostar allt mer att hålla igång.
Att inte spara allt är lösningen.
Själva termen ‘zero copy’ syftar på att data hämtas i realtid från en källa och användas på en annan plats utan att kopieras, återskapas eller flyttas till ett annat system.
Zero-copy i Braze är inte en enskild sak - det är två delar som kan användas tillsammans eller för sig.
Connected Sources för segmentering
Connected Sources låter Braze köra SQL direkt mot ert warehouse för att skapa segment, så kallade CDI Segment Extensions. Bara matchande user ID:n överförs till Braze. Den underliggande datan - attributen, tabellraderna, värdena som avgjorde matchningen - lämnar aldrig warehouset.
Det är det ursprungliga zero-copy-mönstret och det täcker segmentdelen av problemet. Ni definierar SQL, Braze kör den och ert segment hålls aktuellt utan att äta datapoints.
Exempel på CDI Segment Extension (Braze, 2026).
OBS! Warehouses som stödjs: Snowflake, BigQuery, Redshift, Databricks och Microsoft Fabric.
Zero-Copy Personalization genom CDI
När ett Canvas triggas för en användare kan Braze fråga ert warehouse i realtid och resultaten skickas in som Canvas entry properties, till exempel “item_1_name” och “cart_total.”
Den datan används för personalisering, Audience Paths och logik i Decision Splits - och sedan är de borta. De finns inte utanför den specifika resan och skrivs inte till användarprofilen.
Det är skillnaden mot ‘skriv-allt-till-profilen-modellen’. Datan är färsk och speglar vad som finns i warehouse vid triggertillfället.
Tillsammans hjälper de här två funktionerna i Braze ditt team att vara mer relevanta, effektivare och hålla systemet rent.
CDI står för Braze Cloude Data Ingestion: https://www.braze.com/docs/user_guide/data/unification/cloud_ingestion
Webshoppen “fisk&asfalt.se” kör en abandoned cart Canvas i Braze. Varukorgsdatan som produkter, aktuella priser och lagerstatus finns i Snowflake och ändras kontinuerligt.
Här är då skillnaden.
Det ‘gamla’ sättet: En CDI-sync skriver varukorgsattribut till varje användares Braze-profil var 15:e minut (snabbaste). Om priset ändras mellan synken och utskicket visar kommunikationen från canvasen inaktuell information. Attributen på profilen sparas också på obestämd tid om de inte skrivs över eller städas bort.
Arbetar vi istället triggerdrivet med Zero-copy:
När en användare överger sin varukorg skrivs en rad till CDI-tabellen för Canvas triggers. Det är den raden som avgör vem som ska in i Canvasen. Ni behöver alltså inte bygga ett separat segment i Braze bara för att fånga just de användarna.
I samma trigger skickas de aktuella uppgifterna om just den användarens varukorg med, till exempel produkter, priser och lagerstatus.
Den informationen kan sedan användas i Canvasens meddelanden och logik. Det som visas för användaren speglar alltså vad som faktiskt fanns i warehouset vid triggertillfället.
Ingenting av detta skrivs till Braze-profilen!
Zero-copy är inte svaret på alla personaliseringsproblem. Det finns begränsningar.
Passar bra för:
Data som ändras snabbare än en 15-minuters sync hänger med i.
Personaliseringsfält som bara är relevanta för ett specifikt trigger-event
Känslig data eller data som inte ska återskapas utanför warehouset
Minska förbrukning av data points i fall då informationen inte behöver sparas.
Team som vill ha renare och mer lättöverskådliga användarprofiler.
Passar inte för:
Realtidssegmentering. Just CDI-segmentuppdateringar sker enligt schema, inte direkt. Behöver ni audiences som uppdateras inom sekunder är event-baserad Canvas-entry rätt modell, inte CDI-segment.
Cross-Canvas-personalisering. Context variables existerar bara inuti det Canvas de skapas i. Du kan inte referera till dem från en annan Canvas eller från en kampanj.
Om attributen kan tänkas behövas för suppression, frequency capping eller Global Control Group.
Consent och opt-in/opt-out. Dessa måste finnas på profilen.
Vem äger servicekontot och rotationscykeln för credentials?
CDI Connected Sources kräver att man sätter upp inloggnings-credentials. De löper ut. Roteras de utan samordning kan integrationen sluta fungera utan förvarning. Hamnar ansvaret mellan teams är det oftast bara en tidsfråga innan något går sönder.
Vilka kolumner behandlar ni som context-only, och har ni dokumenterat varför?
Om ni inte dokumenterar vilka fält som stannar i warehouset istället för att skrivas till Braze kommer nästa person som tar över uppsättningen antingen undra varför attributet saknas eller lägga till en sync som dubblar samma data.
Om frågan mot warehouset fallerar vid triggertillfället behöver ni bestämma vad som ska hända.
Ska utskicket stoppas? Ska tomma fält visas? Ska det finnas en fallback? Det måste bestämmas innan det händer live.
Finns det dataresidens- eller avtalsbegränsningar på vilken data som får lämna warehouset?
Zero-copy låter ofta som det säkra integritetsvalet. Men i CDI Canvas trigger-flödet lämnar datan fortfarande warehouset i sändningsögonblicket. Den sparas bara inte i profilen. Om data omfattas av ett DPA eller andra begränsningar räcker det därför inte att säga att ni inte lagrar det.
Det är lätt att beskriva zero-copy personalization som ett tekniskt beslut. Men det är inte hela sanningen.
Ni går från ett arbetssätt där Braze också blir lagringsplats för personaliseringsdata till ett arbetssätt där ert warehouse får en större roll. Då blir hur väl det fungerar en större del av hur tillförlitlig er kommunikation från Braze är.
Om det inte från början är samma team som sköter båda delarna blir därför samarbetet mellan ni som arbetar i Braze och det team som underhåller det mer tekniska, ännu viktigare.
Det är därför de team som lyckas arbeta ‘zero-copy’ inte hoppar direkt in i implementationen. De börjar med arbetssättet.
Har ni frågor om zero-copy eller hur ni tar er framåt i ert marketing automation arbete? Tveka inte att kontakta oss så hjälper vi er!
