Advanced Klaviyo Data Platform ingår inte i Klaviyos standardmarknadsföringsapplikation och en prenumeration krävs för att få tillgång till tillhörande funktionalitet. Gå till vår faktureringsguide om du vill läsa mer om hur du köper den här planen.
I den här artikeln använder vi termen ”tabell”, men visningar, materialiserade visningar och tabeller är alla giltiga Snowflake-objekt som kan importeras. Så länge Klaviyo kan köra SELECT col1 FRÅN table_name på objektet är du fri att använda vad du vill.
Nyckelorden "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" och "OPTIONAL" i det här dokumentet ska tolkas enligt beskrivningen i RFC 2119.
Snowflake Admin-konfiguration
Detta avsnitt beskriver de steg du måste följa i din Snowflake-miljö för att tillåta Klaviyo att importera dina data.
- Skapa en privat nyckel genom att köra följande kommando i din lokala terminal:
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt - Generera en offentlig nyckel som refererar till den privata nyckeln genom att köra följande kommando i din terminal:
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub - Kopiera rsa_key.pub och klistra in den i skriptet nedan för att ersätta platshållaren ”GENERATE_PUBLIC_KEY”-värdet för user_rsa_public_key. Skriptet nedan fungerar för Mac-användare, eller så kan du öppna rsa_key.pub i en IDE och kopiera hela innehållet i filen om du föredrar det.
# Mac terminal command to write the key to your terminal and copy it to the clipboard cat rsa_key.pub | tee /dev/tty | pbcopy - Kör följande skript i din Snowflake-miljö för att skapa en tjänstanvändare som Klaviyo kan använda. Du måste ha behörighet för securityadmin och sysadmin för att kunna slutföra konfigurationen nedan. För att se vilken roll/vilka roller du har kör du VISA BIDRAG TILL ANVÄNDAREN <your_username> och ser till att du har båda rollerna listade. Kontakta en systemadministratör om du behöver justera din roll.
- Du är välkommen att uppdatera någon av de variabler som anges i början av skriptet.
- Sammanfattningsvis kommer du att:
- Välj ett befintligt lager eller skapa ett nytt
- Välj en befintlig databas eller skapa en ny för de nya schemana
- Skapa två nya scheman
KLAVIYO_TMPochKLAVIYO_IMPORT_FROM_DWH - Skapa en ny nätverksprincip och tillåt lista med Klaviyo-IP-adresser
- Skapa en användare och roll för Klaviyo
- Detta skript är idempotent (kan köras säkert flera gånger), men kommer inte att skriva över befintliga objekt med motstridiga namn.
BEGIN;
-- create variables for user / password / role / warehouse / database.
-- Change these to whatever you prefer.
SET role_name = 'KLAVIYO_DATA_TRANSFER_ROLE'; -- all letters must be uppercase, ex. 'KLAVIYO_DATA_TRANSFER_ROLE'
SET user_name = 'KLAVIYO_DATA_TRANSFER_USER'; -- all letters must be uppercase, ex. 'KLAVIYO_DATA_TRANSFER_USER'
SET warehouse_name = 'KLAVIYO_DATA_TRANSFER_WAREHOUSE'; -- all letters must be uppercase, ex. 'KLAVIYO_DATA_TRANSFER_WAREHOUSE'
SET database_name = 'KLAVIYO_DATABASE'; -- all letters must be uppercase, ex. 'KLAVIYO_DATABASE'. If this database doesn't exist, a new one will be created.
SET network_policy = 'KLAVIYO_DATA_TRANSFER_NETWORK_POLICY'; -- all letters must be uppercase, ex. 'KLAVIYO_NETWORK_POLICY'
SET network_rule = 'KLAVIYO_DATA_TRANSFER_NETWORK_RULE'; -- all letters must be uppercase, ex. 'KLAVIYO_NETWORK_RULE'
/* replace GENERATE_PUBLIC_KEY below with generated public key */
-- DO NOT CHANGE
SET schema_name_tmp = $database_name || '.KLAVIYO_TMP'; -- DO NOT CHANGE
SET schema_name_import = $database_name || '.KLAVIYO_IMPORT_FROM_DWH'; -- DO NOT CHANGE
SET full_network_rule_tmp = $schema_name_tmp || '.' || $network_rule; -- DO NOT CHANGE
SET full_network_rule_import = $schema_name_import || '.' || $network_rule; -- DO NOT CHANGE
-- change role to sysadmin for warehouse / database steps
USE ROLE sysadmin;
-- create a warehouse for data transfer service
CREATE WAREHOUSE IF NOT EXISTS IDENTIFIER($warehouse_name)
warehouse_size = xsmall
warehouse_type = standard
auto_suspend = 60
auto_resume = true
initially_suspended = true;
-- create database for data transfer service
CREATE DATABASE IF NOT EXISTS IDENTIFIER($database_name);
-- create schemas for data transfer service
CREATE SCHEMA IF NOT EXISTS IDENTIFIER($schema_name_tmp);
CREATE SCHEMA IF NOT EXISTS IDENTIFIER($schema_name_import);
-- change role to securityadmin for user / role steps
USE ROLE securityadmin;
-- create network rule and policy for database
GRANT USAGE ON DATABASE IDENTIFIER($database_name) TO ROLE securityadmin;
GRANT USAGE, CREATE NETWORK RULE ON SCHEMA IDENTIFIER($schema_name_tmp) TO ROLE securityadmin;
GRANT USAGE, CREATE NETWORK RULE ON SCHEMA IDENTIFIER($schema_name_import) TO ROLE securityadmin;
-- whitelist klaviyo ip ranges, for KLAVIYO_TMP schema
CREATE NETWORK RULE IF NOT EXISTS IDENTIFIER($full_network_rule_tmp)
type = IPV4
value_list = (
'184.72.183.187/32', '52.206.71.52/32', '3.227.146.32/32', '44.198.39.11/32', '35.172.58.121/32', '3.228.37.244/32', '54.88.219.8/32', '3.214.211.176/32'
)
comment = 'Klaviyo IP Ranges as of April 2025';
CREATE NETWORK POLICY IF NOT EXISTS IDENTIFIER($network_policy)
allowed_network_rule_list = ($full_network_rule_tmp);
-- whitelist klaviyo ip ranges, for KLAVIYO_IMPORT_FROM_DWH schema
CREATE NETWORK RULE IF NOT EXISTS IDENTIFIER($full_network_rule_import)
type = IPV4
value_list = (
'184.72.183.187/32', '52.206.71.52/32', '3.227.146.32/32', '44.198.39.11/32', '35.172.58.121/32', '3.228.37.244/32', '54.88.219.8/32', '3.214.211.176/32'
)
comment = 'Klaviyo IP Ranges as of April 2025';
CREATE NETWORK POLICY IF NOT EXISTS IDENTIFIER($network_policy)
allowed_network_rule_list = ($full_network_rule_import);
-- create role for data transfer service
CREATE ROLE IF NOT EXISTS IDENTIFIER($role_name);
GRANT ROLE IDENTIFIER($role_name) TO ROLE sysadmin;
-- create a user for data transfer service
CREATE USER IF NOT EXISTS IDENTIFIER($user_name)
type = SERVICE
network_policy = $network_policy
default_role = $role_name
default_warehouse = $warehouse_name
rsa_public_key = 'GENERATE_PUBLIC_KEY';
GRANT ROLE IDENTIFIER($role_name) TO USER IDENTIFIER($user_name);
ALTER USER IDENTIFIER($user_name) SET NETWORK_POLICY = $network_policy;
-- grant service role access to warehouse
GRANT USAGE
ON WAREHOUSE IDENTIFIER($warehouse_name)
TO ROLE IDENTIFIER($role_name);
-- grant service access to database
GRANT MONITOR, USAGE
ON DATABASE IDENTIFIER($database_name)
TO ROLE IDENTIFIER($role_name);
-- Grant privileges for KLAVIYO_TMP
GRANT USAGE ON SCHEMA IDENTIFIER($schema_name_tmp) TO ROLE IDENTIFIER($role_name);
GRANT MONITOR, USAGE, CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE FUNCTION, CREATE PROCEDURE
ON SCHEMA IDENTIFIER($schema_name_tmp)
TO ROLE IDENTIFIER($role_name);
GRANT ALL ON FUTURE TABLES IN SCHEMA IDENTIFIER($schema_name_tmp) TO ROLE IDENTIFIER($role_name);
-- Grant privileges for KLAVIYO_IMPORT_FROM_DWH
GRANT USAGE ON SCHEMA IDENTIFIER($schema_name_import) TO ROLE IDENTIFIER($role_name);
GRANT SELECT
ON FUTURE TABLES
IN SCHEMA IDENTIFIER($schema_name_import)
TO ROLE IDENTIFIER($role_name);
COMMIT;Snowflake-datakonfiguration
Ovan skapade du två nya scheman.
- KLAVIYO_TMP kommer att användas exklusivt av Klaviyo. Du FÅR INTE ändra några tabeller som skapats i detta schema. Klaviyo kommer att radera dessa tabeller när de inte längre behövs.
- KLAVIYO_IMPORT_FROM_DWH är platsen du bör lagra dina slutliga tabeller som Klaviyo kan importera. När du går igenom processen för att skapa synkroniseringen kommer alla tabeller i detta schema att listas så att du kan välja mellan dem. Därför BÖR du bara lagra de slutliga tabellerna som du vill importera för att undvika förvirring under konfigurationen.
Alla tabeller som du planerar att importera till Klaviyo måste uppfylla följande kriterier.
Krav på tidsstämpel
-
Tabellerna MÅSTE innehålla ett tidsstämpelfält som indikerar när raden skapades eller uppdaterades. Ofta kommer detta att vara inserted_at eller updated_at. Du kommer att ställa in detta för varje tabell under synkroniseringsprocessen.
- Tidsstämpelfältet MÅSTE öka monotont (dvs. det måste alltid bli större eller förbli detsamma, aldrig bli mindre).
- När synkroniseringen har skapats FÅR du INTE ställa in en rads tidsstämpelvärde till en tid i det förflutna, eller så kanske Klaviyo inte plockar upp den raden.
- Tidszonen för detta specifika fält är inte viktig för Klaviyo, så länge du följer ovanstående krav
- Dina tidsstämplar MÅSTE vara i UTC eller innehålla information om tidszon. Om tidszoninformation saknas kommer Klaviyo att anta UTC. För anpassade egenskaper förblir dessa tidsstämplar i strängformat, så att du kan tolka dem i din önskade tidszon.
- Tidsstämpelfältet MÅSTE återspegla när raden infogades och ska grupperas nära dagens datum. Klaviyo synkroniserar data genom att skanna 1-timmesfönster från det äldsta tidsstämpelvärdet i din tabell. En enda rad med en tidsstämpel långt tillbaka i tiden (till exempel en 2023-registrering när alla andra är nya) gör att Klaviyo itererar genom varje 1-timmesfönster från detta datum och framåt på varje synkroniseringscykel. Detta är en aktuell begränsning som bör lösas i en kommande version.
- Ta hänsyn till raddensitet per 1-timmes tidsstämpelfönster. Eftersom data läses in i omgångar med tidsstämpelfönster på 1 timme kan miljontals poster i samma timmesfönster leda till långsamma eller avstannade synkroniseringar. Den övre gränsen för raddensitet beror på mängden data i varje rad, men en bra tumregel att tänka på är 100 000 rader per tidsstämpelfönster på 1 timme.
- Klaviyo rekommenderar att du ställer in tidsstämpelfältet med CURRENT_TIMESTAMP() eller en likvärdig funktion när du lägger till rader i tabellen som vi synkroniserar från. Flera rader kan ha samma tidsstämpel. Se exempel nedan.
INSERT INTO table_name AS
SELECT ...
, CURRENT_TIMESTAMP() AS inserted_at
... Tabellstruktur
- Tabeller SKA behandlas som endast bilagor (även kallade insert-only)
- Om du föredrar att uppdatera raderna på plats istället MÅSTE du uppdatera tidsstämpelfältet så att Klaviyo kan identifiera ändringen.
- Tabeller SKA ordnas i din tidsstämpelkolumn. Snowflake kommer att hantera klustring och partitionering baserat på din infogningsbeställning. Detta hjälper till att optimera Klaviyos importfrågor och hålla nere beräkningskostnaderna i Snowflake
Profilens Unikhet och Konsekvens
- Du MÅSTE se till att varje profilegenskap bara importeras från en datakälla (tabell). Klaviyo förhindrar att samma egenskap väljs från olika tabeller när synkroniseringen skapas, vilket förenklar detta krav.
- Du BÖR använda samma profilidentifierare (e-post, telefonnummer, externt ID, etc.) i alla dina importtabeller för att minimera risken för att dubblettprofiler skapas.
- Klaviyo kommer att skapa en ny profil om den profilidentifierare du anger inte matchar en befintlig profil inom Klaviyo.
- Exempel: Tabell1 (E-post, fav_color) + Tabell2 (Telefon, födelsedag)
- Detta kan skapa två profiler för samma person om profilen för närvarande inte finns. Om en profil finns kommer Klaviyo att hantera profillösningen och uppdatera internt.
- Ett sätt att undvika detta problem är att bara använda en enda importtabell för alla dina profiler.
Cirkulärt import-exportloopskydd
- Du BÖR noggrant hantera scenarier där både import- och exportfunktioner används för att förhindra cirkulära import-exportslingor. Se till att din exportprocess inte matar tillbaka data till en tabell som är uppströms din importerade tabell, eftersom Klaviyo för närvarande inte detekterar detta scenario.
- Klaviyo har ännu inte någon logik för att upptäcka detta scenario.
- Detta skulle se ut ungefär så här:
- Vid varje exportsynkroniseringscykel kommer Klaviyo att exportera alla dina profiler
- Sedan lägger du till alla dina exporterade profiler i din importerade tabell genom några serier av transformationer.
- Vid varje importsynkroniseringscykel kommer Klaviyo att läsa alla profiler i din importerade tabell, som så småningom kommer att återexporteras
- Scenarier där detta förmodligen är säkert
- om du bara använder exporttabellen för att begränsa de rader som läggs till i din importerade tabell
- Om du kontrollerar att exporttabellen inte lägger till rader i din importerade tabell.
- Vilka konsekvenser får en cirkulär import-exportslinga?
- Detta kommer att leda till onödiga beräkningskostnader för både dig och Klaviyo.
Felsökning
Synkroniseringen verkar ha fastnat
Om din synkronisering körs men data inte visas i Klaviyo efter flera timmar, eller om synkroniseringen tar ovanligt lång tid att slutföra, är ett tidsstämpelvärde långt tillbaka i tiden den mest sannolika orsaken:
- Kontrollera din tabell för eventuella rader med en tidsstämpel som är betydligt äldre än resten av dina data (till exempel en rad från 2023 när alla andra är från den senaste veckan). Till och med en enda avlägsen rad tvingar Klaviyo att iterera genom tusentals tomma 1-timmesfönster innan de når nya data.
- Reparation: Uppdatera eller ta bort alla rader med tidsstämplar långt tillbaka i tiden, eller ställ in dem på ett nyligen angivet värde, innan du aktiverar eller återaktiverar synkroniseringen. För återfyllning ställer du in alla historiska rader till samma senaste tidsstämpel (t.ex. det aktuella jobbets körtid) för att minimera antalet 1-timmesfönster som Klaviyo måste söka igenom. Om det finns fler än ~100 000 rader anger du deras tidsstämplar i omgångar om ~100 000 med (minst) 61 minuters mellanrum.
Rekommenderade konfiguration av Snowflake-klusternyckel
Genom att gruppera din Snowflake-tabell i tidsstämpelkolumnen kan Klaviyos importfrågor hoppa över onödiga mikropartitioner, vilket minskar både synkroniseringstiden och dina Snowflake-beräkningskostnader:
ALTER TABLE your_database.KLAVIYO_IMPORT_FROM_DWH.your_table CLUSTER BY (your_timestamp_column);