AI voor dynamic pricing — technische implementatie en ethiek

AI voor dynamic pricing — technische implementatie en ethiek

Webshops die dynamic pricing inzetten, zien gemiddeld 5-15% margegroei zonder volumeverlies. Toch maakt minder dan 8% van de Nederlandse e-commerce bedrijven er gebruik van. De technologie is beschikbaar, betaalbaar en inzetbaar in Magento én Shopify. De drempel zit niet in de code — die zit in het begrip van wat je meet, hoe je het bouwt, en waar de grenzen liggen.

Dit artikel behandelt de volledige stack: van datapunten en modellen tot integratie, A/B-testing op marge-impact, en de juridische en ethische grenzen die je niet wilt overschrijden.

Wat is AI-gedreven dynamic pricing?

Dynamic pricing past prijzen aan op basis van realtime signalen. Dat kan eenvoudig zijn — een regel die prijs verhoogt als voorraad daalt — of complex: een ML-model dat vraagcurven, concurrentieprijzen, tijdstip, weerdata en klantgedrag combineert.

Het onderscheid met gewone regels: een regelgebaseerd systeem reageert op vastgelegde triggers. Een AI-model leert patronen die je niet vooraf hebt gedefinieerd, en optimaliseert naar een doel (marge, omzet, sell-through rate).

Beide aanpakken zijn legitiem. De keuze hangt af van assortimentgrootte, datakwaliteit en budget.

Datapunten: wat je minimaal nodig hebt

Een model is zo goed als zijn input. Wij zien bij klanten dat slechte data de belangrijkste oorzaak is van mislukte dynamic pricing-projecten — niet een verkeerd algoritme.

• Historische verkopen per SKU (minimaal 90 dagen, liefst 2 jaar)
• Huidige voorraadniveaus en inkoopprijs
• Categoriestructuur en productattributen
• Conversieratio per prijs-/kanaalcombinatie

• Concurrentieprijzen via scraping of een feed-aggregator (bijv. Prisync, Minderest)
• Seizoens- en eventkalender
• Vraagprognoses op categorie- of merkniveau

Modelaanpak: van simpel naar complex

Optie 1: Rule-based pricing (geen ML)

Voor webshops met minder dan 5.000 SKU's of zonder historische data is een regelgebaseerde aanpak sneller en transparanter. Je definieert prijsbanden, triggers en maximale afwijkingen.

def calculate_price(base_price, stock_level, competitor_price):
    price = base_price

    # Schaarste-opslag: onder 10 stuks +8%
    if stock_level < 10:
        price *= 1.08

    # Concurrentie-floor: nooit meer dan 5% boven concurrent
    if competitor_price and price > competitor_price * 1.05:
        price = competitor_price * 1.05

    # Minimale marge: nooit onder cost_price * 1.20 (elders berekend)
    return round(price, 2)

Simpel, auditeerbaar, geen black box. Nadeel: je vangt geen niet-lineaire patronen op.

Optie 2: Gradient Boosting (XGBoost / LightGBM)

Voor middelgrote assortimenten (5.000-100.000 SKU's) werkt een gradient boosting model goed. Je traint op historische prijs-vraag-data en voorspelt de optimale prijs per context.

Features die wij in de praktijk inzetten:

• price_relative_to_market (jouw prijs / gemiddelde concurrenten)
• days_since_last_sale, stock_coverage_days
• category_demand_index (rolling 14-daags gemiddelde)
• day_of_week, week_of_year

Training: maandelijks hertrainen is voor de meeste webshops voldoende. Dagelijks inference via een lichte API-laag.

Optie 3: Reinforcement Learning

RL-modellen leren door te experimenteren: ze testen prijzen en optimaliseren op basis van ontvangen rewards (bijv. marge per bezoek). Dit is de meest krachtige aanpak, maar ook de meest complexe.

Advies: start hier pas mee als je een stabiele datastroom hebt van minstens 500 transacties per dag per prijssegment. Zonder voldoende volume leert het model niets bruikbaars en introduceert je onnodige ruis.

Integratie in Magento en Shopify

Magento 2

// Plugin op Magento\Catalog\Model\Product
public function afterGetPrice(\Magento\Catalog\Model\Product $subject, $result)
{
    $dynamicPrice = $this->pricingApiClient->getPrice(
        $subject->getSku(),
        $this->customerContext->getGroupId()
    );

    return $dynamicPrice ?? $result;
}

De externe pricing API retourneert een prijs (of null als er geen dynamische prijs beschikbaar is), de plugin valt terug op de catalogusprijs. Houd de response gecached op SKU-niveau — reken op 50-100ms latency per API-call zonder cache, wat checkout-performance raakt.

Gebruik een Redis-cache met een TTL van 5-15 minuten. Zo balanceer je versheid van de prijs met performance.

Shopify Plus

Een Shopify Function in Rust of JavaScript past prijzen aan op cart-niveau, vóór checkout. Voor product-level display-prijzen gebruik je een storefront API-call die de dynamic price ophaalt en via JavaScript in de pagina injecteert.

Nadeel: prijzen in de PLP zijn niet realtime te overschrijven zonder volledige storefront-custom build. Bij een headless Shopify-setup met Laravel als backend heb je meer vrijheid.

A/B-testen van marge-impact

Dit is waar veel implementaties de mist in gaan. Teams meten conversieratio in plaats van marge per bezoek. Een hogere conversie bij een lagere prijs is geen winst — het kan omzetverdunning zijn.

MPS = (verkoopprijs - inkoopprijs) × conversieratio

Een prijs van €49 met 4,2% conversie (MPS: €2,10 bij 30% marge) wint van €44 met 5,1% conversie (MPS: €1,68 bij 30% marge).

• Splits op sessie-ID of cookie, niet op gebruikersgroep (voorkomt price-fairness-klachten)
• Minimale testduur: 2 weken per variant, langer bij lage traffic
• Significantieniveau: 95% minimum, liever 99% bij prijswijzigingen boven 10%
• Sluit promotieperiodes uit van de testwindow

Wij raden aan om maximaal 15-20% van het verkeer in een prijstest te zetten. Zo bescherm je marge terwijl je leert.

Juridische en ethische grenzen

Dit onderwerp wordt te vaak overgeslagen in technische artikelen. Ten onrechte — want hier zitten de echte risico's.

Prijsdiscriminatie

De Europese Omnibus-richtlijn (2021, geïmplementeerd in Nederland per 2023) verplicht transparantie over kortingen: je moet de laagste prijs van de afgelopen 30 dagen tonen als referentieprijs. Dynamic pricing die neerwaartse bewegingen verbergt om kortingen groter te laten lijken, is in strijd met deze richtlijn.

Wat wel mag: prijzen aanpassen op basis van vraag, voorraad, tijdstip of kanaal.

Wat niet mag: prijzen differentiëren op basis van persoonskenmerken (postcode als proxy voor inkomen, geslacht, etniciteit). Dit valt onder de Algemene wet gelijke behandeling en kan als onrechtmatige prijsdiscriminatie worden aangemerkt.

Vertrouwen en prijstransparantie

Amazon verloor in 2000 marktaandeel en vertrouwen nadat bleek dat dezelfde DVD's aan verschillende klantgroepen voor verschillende prijzen werden aangeboden. De techniek was legaal; het vertrouwensverlies was reëel.

Praktische richtlijnen:

• Communiceer tijdgebonden aanbiedingen duidelijk als zodanig
• Toon geen nep-urgentie ("nog 2 beschikbaar") bij kunstmatige schaarste
• Sla prijshistorie op per SKU — ook voor intern gebruik en mogelijke audits
• Zorg dat je pricing-logica uitlegbaar is aan een klant die vraagt waarom zijn prijs anders is

GDPR en gedragsdata

Als je klantgedrag uit CRM of browse-geschiedenis gebruikt voor pricing, val je onder GDPR-verwerking. Verwerk alleen met een rechtsgeldige grondslag, documenteer dit in je verwerkingsregister, en bied opt-out mogelijkheden voor gepersonaliseerde pricing.

Wanneer is dynamic pricing NIET de juiste keuze?

Eerlijk zijn over beperkingen bouwt vertrouwen — ook in dit artikel.

• Je minder dan 200 transacties per maand hebt — te weinig data voor zinvolle modellen
• Je assortiment grotendeels bestaat uit vaste adviesverkoopprijzen (fabrikant-MAP-beleid)
• Je team geen capaciteit heeft voor monitoring — een slecht gecalibreerd model kan prijzen richting kostprijs of boven marktprijs sturen zonder dat je het ziet
• Je primaire concurrentievoordeel niet op prijs ligt — dan investeer je beter in content, UX of service

Implementatiestappen samengevat

1. Data-audit — inventariseer beschikbare historische data, kwaliteit en volume
2. Bepaal aanpak — rule-based, ML of RL (begin simpel)
3. Bouw de pricing API — lichte service, gecached, met fallback op catalogusprijs
4. Integreer in platform — plugin (Magento) of Function/storefront JS (Shopify)
5. Stel monitoring in — alerts op prijzen buiten bandbreedte, MPS-dashboard
6. A/B-test op marge — niet op conversie
7. Juridische review — Omnibus-richtlijn, GDPR, MAP-beleid

Wil je weten welke aanpak past bij jouw assortiment en tech stack? Neem contact op — we kijken graag mee.

Veelgestelde vragen

Dat hangt sterk af van de aanpak. Een rule-based systeem op een bestaande Magento of Shopify-installatie kost doorgaans 20-40 uur ontwikkeling. Een volledig ML-gedreven systeem met externe datafeed, hertraining en monitoring: reken op 3-6 maanden doorlooptijd en een dedicated data-infrastructuur. Veel klanten starten met een hybride aanpak — regels voor 80% van het assortiment, ML voor de top-200 SKU's.

Ja, mits transparant en niet gebaseerd op beschermde kenmerken (zoals herkomst of geslacht). Loyaliteitskortingen, volume-kortingen of B2B-prijzen zijn legitiem. Verborgen prijsdifferentiatie op basis van betalingsbereidheid of demografische proxies is juridisch en ethisch risicovol.

Meet marge per sessie (MPS), niet conversieratio. Een hogere conversie bij een lagere prijs kan netto minder opleveren. Kijk ook naar sell-through rate bij seizoensartikelen en klanttevredenheidsscores op langere termijn — prijsfluctuaties die klanten verwarren, kosten je retentie.

Bij minder dan 200 transacties per maand is het model te weinig data om goed te kalibreren. Een simpel rule-based systeem (schaarste-opslag, concurrentiematching) kan al wel werken — dat vereist geen ML en is binnen een sprint te bouwen op zowel Magento als Shopify.