Waarom de prijs in je vergelijkingslisting achterloopt op de prijs in je webshop

Een bezoeker klikt door vanuit een vergelijkingslisting en verwacht 149 te betalen. Op de productpagina staat 164. Hij gaat terug, klikt op de volgende shop, en jij hebt betaald voor een klik die nooit had kunnen converteren. Gebeurt dat vaak genoeg, dan markeert een vergelijkingssite je feed, haalt ze aanbiedingen offline die ze niet vertrouwt, of vraagt ze je dit eerst te herstellen voordat je weer wordt getoond.

Een prijsverschil komt zelden doordat iemand een verkeerd getal heeft ingetypt. Het is vrijwel altijd een kwestie van timing of definitie: de feed is op het ene moment gegenereerd en op het andere uitgelezen, of het getal in de feed betekent net iets anders dan het getal op de pagina. Beide zijn op te lossen, maar pas zodra je kunt zien waar de vertraging precies zit.

De vier klokken tussen je database en de listing

Er is niet één moment waarop jouw prijs zichtbaar wordt op een vergelijkingssite. Het zijn er minstens vier, en elk moment voegt vertraging toe.

Generatie. De meeste shops bouwen de XML volgens een schema, bijvoorbeeld een cron job om 03:00, en schrijven die weg naar een statisch bestand. Alles wat na 03:00 verandert, is onzichtbaar tot de volgende run. Genereer je maar één keer per dag, dan is je worstcase-verouderingstermijn al 24 uur, nog voordat je iets anders meetelt.

Ophalen. De vergelijkingssite leest het bestand volgens haar eigen schema, dat wel of niet aansluit op het jouwe. Genereer je om 03:00 en haalt de site het bestand om 02:30 op, dan loopt je listing een volle dag achter op je bestand, niet een paar minuten.

Caching. Hier trappen mensen het vaakst in. Een CDN of reverse proxy voor je feed-URL serveert met plezier uren na het wegschrijven van een vers bestand nog een gecachte kopie. Het bestand op schijf klopt, het bestand dat je eigen browser toont klopt omdat je de origin raakt, en de versie die de crawler binnenkrijgt is van gisteren. Controleer de responseheaders van je feed-URL van buiten je eigen netwerk: Cache-Control, Age en Last-Modified laten meteen zien of er onderweg iets een kopie vasthoudt.

Verwerking van de import. Grote feeds kosten tijd om te parsen, te matchen en te indexeren. Dat zijn meestal minuten in plaats van uren, maar het is niet nul.

Tel ze eerlijk bij elkaar op. Een shop die dagelijks genereert en dagelijks wordt opgehaald, heeft in de praktijk een verouderingstermijn van maximaal twee dagen, niet “ongeveer een dag”. Een shop die elk uur genereert, de feed zonder cache serveert en om de paar uur wordt opgehaald, zit een paar uur van live af.

Bepaal je tolerantie en kies dan een schema

De juiste generatiefrequentie hangt af van hoe snel je prijzen bewegen. Als je automatisch herprijst op basis van concurrenten, is een dagelijkse feed niet te verdedigen: je adverteert dan met een prijs die je voor de lunch alweer hebt losgelaten. Stel je prijzen met de hand in en pas je ze een paar keer per maand aan, dan levert uurlijkse generatie je niets op.

Een praktische vuistregel: je generatie-interval moet korter zijn dan de tijd die een prijswijziging nodig heeft om commercieel te tellen. Voor de meeste shops betekent dat elk uur voor prijs en voorraad, terwijl de zwaardere beschrijvende velden minder vaak opnieuw worden opgebouwd.

Is het te duur om de hele catalogus elk uur te genereren, splits de klus dan op. Bouw de volledige feed één keer per dag en houd de prijs- en beschikbaarheidsvelden bij in een snellere cyclus: door alleen die velden opnieuw naar hetzelfde bestand te schrijven, of door een aparte lichte feed te publiceren als de vergelijkingssite die ondersteunt. Zoek eerst uit wat het kanaal accepteert voordat je het bouwt; niet elk kanaal neemt een delta aan.

Zorg dat het getal op beide plekken hetzelfde betekent

Los van timing is er een tweede soort afwijking: de prijs wordt in de feed anders berekend dan op de pagina.

• Btw. De feed moet de prijs bevatten die de consument betaalt, inclusief btw. De klassieke fout is een export die de nettoprijs uit de database haalt en er btw op zet met een andere afronding dan de storefront, waardoor de listing op 82,64 staat en de pagina op 82,65. Eén cent is genoeg om een geautomatiseerde prijscontrole te laten aanslaan.
• Afronding en opmaak. Gebruik een punt als decimaalteken, twee decimalen, geen duizendtalscheiding en geen valutasymbool in het getal, tenzij de specificatie daarom vraagt. 1,299.00 en 1 299,00 € veroorzaken parsefouten of, erger, stille verkeerde interpretaties.
• Prijzen per klantgroep. Toont je shop andere prijzen aan ingelogde klanten, zakelijke accounts of nieuwsbriefabonnees, dan moet de feed de prijs bevatten die een anonieme bezoeker ziet. Exports die onder een adminsessie draaien, pakken soms per ongeluk een personeelskorting op.
• Kortingscodes. Een prijs die alleen geldt met een code in de checkout is niet de feedprijs. Zo'n prijs in de feed zetten is een snelle manier om het vertrouwen van zowel bezoekers als het kanaal kwijt te raken.
• Variantprijzen. Toont een productpagina standaard de goedkoopste variant, terwijl je feed het hoofdproduct exporteert tegen een gemiddelde of de hoogste prijs, dan komen die twee nooit overeen. Exporteer elke variant als apart item met een eigen prijs en een eigen identifier.
• Verzendkosten. Zet de bezorgkosten in het verzendveld, niet verwerkt in de prijs. Bezoekers sorteren vaak op totaalprijs, en de vergelijkingssite heeft de twee bedragen apart nodig om die te berekenen.

Acties zijn waar de meeste verschillen ontstaan

Een actie die om middernacht begint en een feed die om 03:00 opnieuw wordt gegenereerd: dat zijn drie uur aan listings met de oude prijs, wat te verdragen is. Een actie die om middernacht eindigt met hetzelfde schema, betekent drie uur adverteren met een prijs die je niet meer hanteert. Dat is de variant die klachten oplevert.

Twee gewoontes helpen. Plan ten eerste direct na elk actiemoment een nieuwe feedgeneratie in, niet alleen op het vaste interval. Wees ten tweede voorzichtig met tijdzones op de server: draait je shop op UTC en staan je campagnes in lokale tijd, dan begint je actie twee keer per jaar een uur te vroeg of te laat. Kijk in welke tijdzone de cronserver denkt te zitten, niet in welke tijdzone jij zit.

Ondersteunt het feedformaat een actieprijs met een geldigheidsperiode, gebruik die dan. Het kanaal laten weten dat een prijs geldt van een bepaalde datum tot een bepaalde datum is betrouwbaarder dan racen om het bestand op het juiste moment opnieuw te genereren.

Voorraadstatus verdient dezelfde zorg als prijs

Een klik op een product dat niet op voorraad is, is net zo verspild als een klik op een verkeerde prijs. Beschikbaarheid verandert meestal sneller dan prijs, dus als je één veld vaak bijwerkt, maak dat dan dit veld.

Wees precies in plaats van optimistisch. “Op voorraad” moet betekenen dat je het kunt verzenden; een levertijd van twee weken bij de leverancier is een andere status en moet ook zo worden aangegeven als de specificatie dat toestaat. Accepteert een feed alleen op voorraad of niet op voorraad, bepaal de regel dan bewust: de meeste shops doen er beter aan producten met een lange levertijd als niet beschikbaar te markeren dan een bezoeker teleur te stellen die levering de volgende dag verwachtte.

De andere helft van het werk is opruimen. Uitgefaseerde producten horen helemaal uit de feed te verdwijnen in plaats van op voorraad nul te blijven staan, en de URL van alles wat is verwijderd, moet een correcte 404 teruggeven of doorverwijzen naar iets relevants, niet naar een leeg template.

Een controleroutine die tien minuten per week kost

Wat je niet ziet, kun je niet herstellen. Zet een eenvoudige vergelijking op tussen de feed en de live shop:

1. Haal je eigen feed-URL op van buiten je netwerk, zoals een crawler dat doet, en noteer de Age-header.
2. Neem een steekproef, bijvoorbeeld vijftig items, met extra gewicht voor je bestsellers en alles wat onlangs is herprijsd.
3. Scrape of controleer van elk item handmatig de prijs en voorraadstatus op de live pagina, en leg die naast de waarden in de feed.
4. Zoek uit waarom iets méér afwijkt dan door afronding te verklaren is, en alles waarvan de timestamp in de feed ouder is dan je opgegeven generatie-interval.

Laat het als geplande script draaien als dat kan, en laat alerts afgaan op een drempelwaarde in plaats van op elk afzonderlijk verschil: een handvol items dat midden in een update zit is normaal, vijftig procent van de catalogus niet. Houd ook het totale aantal items tussen runs in de gaten: een feed die plotseling een derde van zijn producten kwijtraakt, wijst meestal op een generatiejob die halverwege is mislukt, niet op een echte wijziging in de catalogus.

De shops die op vergelijkingskanalen de minste problemen hebben, zijn niet die met de meest uitgebreide feeds. Het zijn de shops waar het getal in het bestand het getal op de pagina is, op elk uur van de dag.