Bed om tidlig adgang til Tajo

Indtast dit fornavn og en e-mailadresse eller et telefonnummer. Vi kontakter dig med oplysninger om adgang til Tajo.

Tajo Team Begynder 12 min

Forstå Shopify-datasynkronisering med Brevo

Hvordan Tajos styrede synkronisering flytter data én vej fra din kilde ind i Brevo: planlagte kørsler, samtykke der fejler lukket, idempotente skrivninger og et fuldt revisionsspor.

Tajo flytter data fra dit kildesystem ind i Brevo gennem styrede synkroniseringsregler: godkendt af mennesker, envejs, kørt efter en tidsplan og logget fra ende til anden. Denne artikel forklarer, hvad det betyder i praksis, og hvad det ikke omfatter.

Hurtigt tjek Denne artikel forudsætter, at du har forbundet Shopify og Brevo og offentliggjort mindst én synkroniseringsregel. Hvis ikke, start med at forbinde Tajo til Shopify.

Formen på en synkronisering

Hver synkronisering i Tajo er en synkroniseringsregel: en gennemgået, godkendt definition af præcis hvad der flyttes, og hvordan. En regel har fire dele, du kan inspicere på dens side under Connectors > Syncs:

DelHvad den gør
FeltmappingHvert kildefelt, det Brevo-felt det skriver til, og enhver transformation imellem
FilterudtrykEvalueret pr. post; poster, der ikke matcher, springes over
CursorSporer, hvor langt synkroniseringen er nået, så hver kørsel fortsætter, hvor den sidste stoppede
KørselshistorikHver kørsel, med antal læste, skrevne og fejlede poster, plus varighed og status

Data flyder i én retning: fra din kilde ind i Brevo. Tajo skriver ikke data tilbage til Shopify.

Hvornår data synkroniseres

Synkroniseringskørsler foregår i planlagte batches, eller på forespørgsel, når du udløser en kørsel fra reglens side. Tajo er ikke en realtidspipeline: en ændring i Shopify når Brevo ved den næste kørsel, ikke inden for sekunder. Det er bevidst: batch-kørsler er det, der gør hver skrivning gennemgåelig, budgetteret og henførbar til en bestemt kørsel i revisionssporet.

Hver kørsel læser nye og ændrede poster siden cursoren, anvender filteret, mapper felterne og skriver til Brevo. Kørselsposten viser præcis, hvor mange poster der blev læst, skrevet og fejlet.

Styringsgarantierne

Samtykke fejler lukket

En synkroniseringsregel kan ikke offentliggøres uden en samtykkepolitik, og ved kørsel bliver en post uden dokumenterbart samtykke ikke skrevet. Når samtykke ikke kan fastslås, siger Tajo nej til skrivningen i stedet for at gætte. Fejltilstanden er altid »for forsigtig«, aldrig »oversendt«.

Kørsler er idempotente

Hver skrivning bærer en oprindelsesnøgle udledt af kildeposten (bygget så den er sikker i forhold til personoplysninger), så en gentagen kørsel af en synkronisering, efter en fejl, en pause eller manuelt, ikke skaber duplikerede skrivninger. Det er altid sikkert at køre en regel igen.

Alt bliver registreret

Offentliggørelse af en regel, hver godkendelsesbeslutning (med sin skriftlige begrundelse) og hver kørsel registreres i revisionssporet. Godkendelsen, der autoriserede en offentliggørelse, er bundet til den præcise regelversion, der blev gennemgået; redigering af reglen gør godkendelsen ugyldig, så revisionssporet altid afspejler, hvad der reelt blev autoriseret.

Fejl sætter reglen på pause

Hvis flere kørsler i træk fejler, sætter en circuit breaker automatisk reglen på pause og viser den seneste fejl på reglens side. Ret årsagen, og genudgiv derefter for at genoptage. En delvist fejlet kørsel rapporterer sit antal fejlede poster, så du præcis kan se, hvad der ikke kom med.

Sådan respekteres afmeldinger

Tajo behandler Brevo som den autoritative kilde for e-mailsamtykke:

  • Når en kontakt afmelder sig via et Brevo-e-mailfooter-link, registreres det fravalg mod kontakten, og Brevo udelukker vedkommende fra fremtidige kampagner.
  • Kontakter, der er sortlistet i Brevo, forbliver udelukket; downstream-udsendelser genopliver dem ikke.
  • Tajo skriver ikke afmeldingsstatus tilbage til Shopify. Hvis du også indsamler e-mailsamtykke i Shopify, skal du håndtere det dér separat; antag ikke, at de to systemer spejler hinanden.

Hvilke data er tilgængelige

Hvad der synkroniseres, afhænger af, hvilke skabeloner der er tilgængelige for din kilde. For Shopify er den typiske form kundeposter, identitetsfelter og ordreudledte attributter som samlet forbrug og antal ordrer, mappet ind i Brevo-kontaktattributter, du kan bruge i segmenter og kampagner. Den præcise mapping for dit workspace er ikke gemt væk i en beskrivelse: åbn synkroniseringsreglen, og læs feltmappingtabellen. Den tabel er det autoritative svar på »hvad synkroniseres«.

Hvad Tajo ikke gør i dag

At være præcis om grænserne betyder mere end en lang funktionsliste:

  • Ingen tovejssynkronisering. Intet skrives tilbage til Shopify, hverken afmeldinger, tags eller engagement-scorer.
  • Ingen realtidssynkronisering. Kørsler er planlagte eller manuelt udløste batches, ikke streaming under et minut.
  • Ingen lagersporing. Produktbeholdningsniveauer overvåges ikke, og der er ingen tilbage-på-lager-triggere.

Hvis en af disse grænser blokerer et brugsscenarie for dig, så fortæl teamet det; prioriteringerne i early access formes netop af den slags feedback.

Hvor du kan se dine data

  • I Tajo: åbn synkroniseringsreglen under Connectors > Syncs for kørselshistorik, cursorposition og antal pr. kørsel. Revisionssporet registrerer offentliggørelser og godkendelser.
  • I Brevo: åbn Contacts, og inspicer en vilkårlig kontakts attributter for at bekræfte, at mappede felter bliver udfyldt. Byg segmenter på de attributter til målretning.

Fejlfinding

  • Kontakter vises ikke i Brevo: tjek reglens seneste kørsel for fejl og dens status (en pauset regel kører ikke). Se manglende kontakter i Brevo.
  • Kørsler fejler gentagne gange: circuit breakeren sætter reglen på pause og viser den seneste fejl. Se data synkroniseres ikke.
  • Duplikerede kontakter: skrivninger er idempotente pr. kildepost, men eksisterende dubletter i Brevo forbliver. Se duplikerede kontakter.

Ofte stillede spørgsmål

Kan jeg gøre synkroniseringen hurtigere? Du kan udløse en kørsel på forespørgsel når som helst fra synkroniseringsreglens side. Der er ingen realtidstilstand.

Hvad sker der, hvis en kørsel fejler undervejs? Kørslen rapporterer sit antal fejlede poster, cursoren rykker kun frem over det, der blev behandlet, og den næste kørsel dækker sikkert det resterende igen; idempotensnøgler forhindrer dubletter.

Kan jeg ændre, hvad der synkroniseres? Ja, rediger reglens feltmapping eller filter. Redigeringen skaber en ny version, der skal gennem godkendelse af offentliggørelse igen, før den træder i kraft.

Hvorfor satte min regel sig selv på pause? Fejl i flere kørsler i træk udløser circuit breakeren. Reglens side viser antallet af fejl og den seneste fejl; ret problemet, og genudgiv.

Relaterede artikler

Få hjælp