Feed Delta Processing

Een volledige feed bevat elk product en elk attribuut in de database en overschrijft alles op de bestemming. Een delta feed bevat alleen de records die zijn gewijzigd sinds de laatste synchronisatie, wat het sneller en efficiënter maakt voor frequente updates.

Om verwijderingen te verwerken, moet het systeem een specifieke 'delete' vlag of een 'tombstone' record sturen voor de SKU. Als het systeem alleen toevoegingen en wijzigingen stuurt, blijven verwijderde items actief op de marketplace.

Marketplaces hebben vaak API-limieten die beperken hoeveel gegevens je per uur kunt verzenden. Delta processing vermindert het datavolume, waardoor je prijzen en voorraad vaker kunt bijwerken zonder deze technische limieten te overschrijden.

Retailers met grote assortimenten besparen aanzienlijk op serverbelasting en verwerkingstijd door alleen gewijzigde data te versturen. Deze efficiëntie maakt frequentere updates mogelijk, waardoor kritieke informatie zoals voorraadniveaus en prijswijzigingen binnen enkele minuten in plaats van uren gesynchroniseerd zijn op alle kanalen.

Een volledige sync is noodzakelijk tijdens de initiële onboarding van een nieuw kanaal of na grote structurele wijzigingen in het datamodel van je PIM. Daarnaast dient een volledige feed als een periodieke reset om eventuele kleine inconsistenties te corrigeren die bij incrementele updates over het hoofd zijn gezien.

Het systeem vergelijkt de huidige staat van een SKU met de laatst opgeslagen versie door middel van hashing of tijdstempels op attribuutniveau. Alleen de velden waar een verschil wordt geconstateerd, zoals een gewijzigde productomschrijving of nieuwe afbeelding-URL, worden gemarkeerd voor verzending naar de externe verkoopkanalen.

Ja, veel PIM- en middleware-oplossingen gebruiken de detectie van een delta om specifieke webhooks of automatiseringen te activeren. Omdat het systeem exact weet wat er is gewijzigd, kan het gericht acties in gang zetten, zoals het informeren van de klantenservice wanneer een product uit assortiment gaat, zonder de hele database te scannen.

Een veelgemaakte fout is het niet periodiek uitvoeren van een volledige synchronisatie. Hoewel delta's efficiënt zijn, kunnen er door netwerkstoringen kleine verschillen ontstaan tussen systemen. Ook het vergeten van 'hard deletes' is een risico; als een product volledig uit het PIM verdwijnt zonder een specifiek verwijdersignaal in de delta, blijft het als 'spookvoorraad' op marketplaces staan. Zorg er daarom voor dat je systeem ook signalen stuurt voor verwijderde items en plan wekelijks een volledige refresh in.

Je meet dit door de verwerkingstijd van een update te vergelijken met een volledige export. Kijk specifiek naar de 'latency': de tijd tussen een prijsaanpassing in je PIM en de zichtbaarheid op het verkoopkanaal. Een gezonde delta feed verwerkt wijzigingen binnen enkele minuten. Daarnaast is de foutratio per batch een belangrijke KPI; als een delta feed vaak faalt door ontbrekende referentiegegevens zoals SKU's, wijst dit op een structureel probleem in de databron.

Gebruik altijd onveranderlijke unieke identifiers, zoals SKU of EAN, om producten te matchen. Sla daarnaast een 'hash' of digitale vingerafdruk van de vorige productstatus op. Zo herkent het systeem direct of er echt iets is gewijzigd voordat de data wordt verzonden. Een andere goede gewoonte is het hanteren van een buffer voor voorraadupdates: stuur bij kleine schommelingen niet direct een update, maar doe dit pas bij significante wijzigingen om onnodig dataverkeer en API-limieten te ontzien.

Stel, je hebt een kledingwinkel met 50.000 artikelen. Gedurende de dag veranderen alleen de prijzen van 100 zomerjurken en de voorraad van 50 sneakers. Zonder delta processing zou je systeem alle 50.000 producten opnieuw moeten uploaden naar Google Shopping. Met delta processing identificeert de software alleen de 150 gewijzigde regels. Deze kleine update wordt binnen seconden verwerkt, waardoor klanten direct de juiste prijs zien en je geen nee hoeft te verkopen op de sneakers.

De e-commerce manager bepaalt de strategie rondom updatesnelheid om de verkoop te optimaliseren. De data-architect of PIM-specialist is verantwoordelijk voor de technische inrichting en het mappen van de velden. Daarnaast monitort de marketplace specialist de foutrapportages in kanalen om te controleren of de delta's correct worden geaccepteerd. Tot slot profiteert de klantenservice indirect, omdat zij minder klachten krijgen over foutieve prijsinformatie of producten die achteraf toch niet op voorraad bleken te zijn.