De verborgen kosten van ‘onschuldige’ segmentaties

Wie klantselecties voor online campagnes maakt, heeft vaak één doel voor ogen: zo relevant en persoonlijk mogelijk segmenteren. Want dat komt ten goede aan de interactie, het sentiment en idealiter conversie. Maar bij deze segmentaties is er nóg een doel dat vaak wordt vergeten, namelijk efficiëntie. Vooral bij omvangrijke klantdatabases kunnen trage rekentijden en overbodige database-calls je hele proces vertragen én onnodig duur maken. Maar wat heb je eraan als je daar wel rekening mee houdt?

Onschuldige segmentaties lopen al snel in de papieren

Veel marketeers bouwen hun segmentaties alsof ze in Excel werken. Elk veld wordt opnieuw opgehaald en elke splitsing opnieuw berekend. Elke stap waarin een segment wordt opgebouwd, wordt telkens opnieuw klantdata opgehaald.

Dit lijkt onschuldig, maar het kan al snel in de papieren lopen door:

• Langere laadtijden tijdens het bouwen van flows
• Trage runs of zelfs falende campagnes
• Onnodige belasting op het dataplatform

Een versimpeld voorbeeld uit de praktijk

Laten we dit vertalen naar een praktijkvoorbeeld. We willen klanten selecteren die een opt-in hebben op het kanaal e-mail en die in de afgelopen 7 dagen iets bij ons besteld hebben. Als je dit in SQL zou opzetten, kom je bijvoorbeeld uit op twee losse queries:

-- Stap 1: eerst alle klanten ophalen met een optin
SELECT customer_id
FROM customers
WHERE email_optin = 'Y'

-- Stap 2: daarna alle klanten ophalen met een order in de laatste 7 dagen
SELECT DISTINCT customer_id
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '7 days'

Als derde stap, leg je deze twee queries over elkaar heen. Bijvoorbeeld met een JOIN. Het nadeel van deze opzet is dat er meerdere database-calls en tussenstappen nodig zijn. En hoe meer calls en stappen, hoe langer de rekentijden en groter de kans op fouten.

Maar het kan ook efficiënter. Bijvoorbeeld door deze vraag te combineren in één query.

SELECT DISTINCT c.customer_id, c.email
FROM customers c
JOIN orders o
ON c.customer_id = o.customer_id
WHERE c.email_optin = 'Y'
AND o.order_date >= CURRENT_DATE - INTERVAL '7 days'

Er is nu nog maar één database-call nodig. Bovendien heb je geen tijdelijke datasets nodig en neemt de kans op fouten aanzienlijk af. Het is niet in elke tooling mogelijk om JOINS toe te passen, maar denk dan aan subqueries als alternatief.

Een afname van 90% in database-calls en 2 uur rekentijd

Zelf heb ik dit niet te lang geleden nog toegepast op zo’n 60 geautomatiseerde campagnes die dagelijks draaien. Met als resultaat een afname van 90% in database-calls en bijna 2 uur in totale rekentijd.

Ook wordt deze opzet nu toegepast op nieuwe ad-hoc campagnes. De winst zit ‘m hier vooral in efficiëntie en kostenbesparing. Kijk je naar andere ESP’s, dan zou dit je winst kunnen zijn:

Haal in één klap de benodigde klanten binnen

Maak zelf eens een overzicht van alle geautomatiseerde segmenten die nu draaien. Hoe lang zijn die daar doorgaans mee bezig en hoeveel records komen er uit? Hier valt misschien al heel snel winst te behalen.

Segmenten die er bovengemiddeld lang over doen en waar onderaan de streep relatief weinig adressen worden benaderd, kun je als eerst aanpakken. Kijk bijvoorbeeld naar deze gegevens, en optimaliseer waar mogelijk:

• Welke tabellen roep je aan?
• Welke tabellen roep je meerdere keren aan?
• Hoeveel records gaan er per stap doorheen?
• Kun je stappen samenvoegen?

Eén goed samengestelde query haalt de benodigde klanten in één klap binnen. Waar meerdere losse queries leiden tot traagheid, onnodigde complexiteit en databasebelasting. Daar ziet de ontvanger van je campagnes misschien niets van terug, maar reken maar dat het intern voor veel winst zorgt!

Home < De verborgen kosten van ‘onschuldige’ segmentaties