[Pricewatch] Prijzen bij een webshop

[H!GHGuY]

Bij het vullen van een winkelmandje kan het voorkomen dat een gebruiker bij 1 of meerdere webshops reeds een account heeft en niet onmiddellijk behoefte heeft om bij nieuwe webshops een account aan te maken.

In zo'n geval kan het interessant zijn om de prijzen die in de productlijst weergegeven worden te filteren op de webshops naar keuze.

Om een voorbeeld te geven:
Gebruiker Jan stelt een nieuwe PC samen en ik wil enkel bij webshop X en Y mijn producten kopen. Wat optische media betreft is Jan niet bepaald kieskeurig en wil hij gewoon kiezen uit de eerste 10 goedkoopste producten van webshop X en Y. Op dit moment zou hij daarvoor moeten de webpagina's van die shops raadplegen en vergelijken.
In het nieuwe systeem filtert Jan de categorie optische media (of misschien zijn wenslijst?) zodat enkel X en Y weergegeven worden. Vervolgens krijgt Jan enkel de producten te zien die in 1 van beide webshops aangeboden worden en kan hij vervolgens een keuze maken.

Voordelen:
- Men kiest niet meer het goedkoopste product in de pricewatch om dan te zien dat die webshop waar je het product wil bestellen plots 10 euro duurder is
- Producten die die webshop niet verkoopt zijn ook meteen niet zichtbaar
- Je hoeft niet meer zelf de websites van de webshops gaan vergelijken voor producten waar je eigenlijk minder belang aan hecht.

Een alternatief zou eruit bestaan dat het PW-systeem gelijkwaardige alternatieven voorstelt bij het berekenen van de prijs. Dit is echter een stuk complexer en foutgevoeliger (wat is een gelijkwaardig alternatief?)

[H!GHGuY]

*bump*

Wordt hier iets mee gedaan, is de beschrijving onduidelijk, ... ?

[Verwijderd]

Het lijkt me een interessante feature!
Zelf dacht ik aan het samenstellen van een lijst en zo een overzicht te krijgen van de verschillende shops en hun totaalprijzen hierbij (met zoals je zegt een +- feature die €X als verschil toelaat per gekozen item - als shop Y bijvoorbeeld een iets andere DVDRW verkoopt dan shop X bijv.)

Op deze manier is het wat makkelijker om de shops te vergelijken op prijs ipv bij elke shop lang te liggen samenstellen om dan te zien dat een bepaald item niet beschikbaar is...

[Yankovic]

+1

Ben zelf op zoek naar wat dingen in de pricewatch, maar wil deze graag bij een specifieke shop bestellen. Nu moet ik steeds kijken of dat product inderdaad ook geleverd wordt door die specifieke shop.

Waarom ik niet meteen naar de website van de shop ga? De meeste shops hebben niet zulke uitgebreide en gebruiksvriendelijke filter- en vergelijkmogelijkheden als de pricewatch :-)

[ACM]

Je kan hier in ieder geval twee dingen doen, beide gebaseerd op onze wenslijstfunctionaliteit die we al jaren hebben

1. Zet je gewenste producten in een wenslijst
2. Maak die wenstlijst "favoriet" (zie Wenslijsten-optie in het menu en dan de bewerkoptie van de wenslijst)
3. Kijk bij de shopreviewoverzichten/winkelpagina's van je favoriete winkel(s). Stel dat is 4Launch, dan zie je rechtsonder "Producten van deze shop in wenslijst" staan.
4. Of, laat je wenslijstje doorrekenen op totaalprijs ("Bestelkosten berekenen" bij de wenslijst), waar je vervolgens per winkel kan zien wat het kost en welke producten ze allemaal kunnen leveren. Je kan dan allerlei dingen aan de zijkant aanpassen, zoals het aantal producten dat je minimaal bij 'de eerste winkel' wilt bestellen en/of welke winkels je wilt negeren in de berekening. Dat laatste is dus eigenlijk het omgekeerde van wat je vraagt, maar je zou ook zonder alle winkels uit die lijstjes aan te vinken een heel eind moeten komen

[H!GHGuY]

Beide approaches zijn nog steeds omslachtig.

Bij de eerste komt het nog altijd voor dat je eerst een productkeuze maakt, om daarna pas te gaan verifieren dat jouw webshops deze ook wel echt leveren. Uiteindelijk moet je dus nog steeds alle webshops overlopen en zelf de rekening maken.
Bij de 2de optie (en dat is degene die ik nu gebruik), moet ik voor elk component die niet bij 1 van de webshops leverbaar is deze uit het mandje gooien en een nieuwe 'gok' doen, tot ik een component gevonden heb die voldoet. Soms ga je dan wel naar de website van die webshops om te zoeken, maar wat is dan nog het nut van de pricewatch?

Beide approaches staan vol van 'do+undo' stappen. Terwijl met een filter, we meteen producten uit de juiste webshops kunnen kiezen.

[F.West98]

Of uit te breiden naar:
Voeg een product toe aan je mandje wat wordt gekozen adhv jouw criteria en het best past in een mandje bij "berekenen".
Dus dat je een mobo kiest: moet 4xUSB3 hebben, socket 1155, 4 ram sloten, enz, enz. Verder maakt het niet uit welk merk, waarna de "bereken"-functie het meest voordelige mobo toont

[jopie]

Dat gebeurt toch eigenlijk al? Na de filters te hebben ingegeven hoef je het product alleen maar in een wenslijst te zetten. Ik zie niet de toegevoegde waarde om dat door tweakers.net te laten doen. Alsof een tweaker geen emotionele voorkeur heeft als er meerdere producten voldoen aan de criteria.

[ACM]

H!GHGuY schreef op donderdag 25 juli 2013 @ 12:27:
Bij de eerste komt het nog altijd voor dat je eerst een productkeuze maakt, om daarna pas te gaan verifieren dat jouw webshops deze ook wel echt leveren. Uiteindelijk moet je dus nog steeds alle webshops overlopen en zelf de rekening maken.

Als je weer een voorkeur voor 1 specifieke webshop hebt, dan kan je nog naar de pagina met alle producten bij een webshop gaan. Die zit nog een beetje verstopt onder '9666 producten' bij 4Launch hier.

Maar het klopt dat we niet zoiets hebben voor een groep webshops.

Beide approaches staan vol van 'do+undo' stappen. Terwijl met een filter, we meteen producten uit de juiste webshops kunnen kiezen.

Als je de algemene lijsten van producten wilt kunnen filteren op webshops, dan ben ik bang dat we je daar voorlopig niet mee gaan helpen.

De uitleg staat zo nu en dan herhaald op het forum, o.a. hier ACM in "\[pricewatch/feature] voorkeurshops bij zoeken producten"

ACM schreef op dinsdag 18 juni 2013 @ 08:28:
De reden dat dit er niet is, is dat er een behoorlijke combinatorische situatie ontstaat die lastig efficient is uit te werken. We hebben gemiddeld iets van 10 prijzen per product, waardoor je bij een lijst van bijvoorbeeld alle 1600 laptops met een prijs dan niet 1600 producten moet filteren, maar daarna ook nog eens van alle 16.000 prijzen moet kijken of ze voldoen aan je criteria en wat dan de overgebleven laagste prijs is.
En binnen een categorie valt dat dan nog wel mee, als je echter een algemene zoekopdracht hebt, of domweg in alle producten gaat bladeren... dan moeten we datzelfde grapje in het ergste geval met zo'n 85.000 producten (en dus 850.000 prijzen) doen.

Uiteraard zijn er wel dingen aan te versnellen, maar doordat de gekozen verzendkostenmethoden in jouw voorstel ook varieren moeten we dan eigenlijk ook nog eerst alle relevante verzendkosten-regels doorrekenen voor ieder van die prijzen. En dat is helaas ook niet altijd een kwestie van domweg 7,50 euro bij de prijs optellen... Als we dat weglaten is het dus al niet heel simpel, maar zeker met dat stukje venijn erbij is het een uitdaging die we voorlopig nog niet aan hebben willen gaan

Daarnaast is het ook nog eens lastig om goed in de GUI te verwerken omdat je naast filters op productniveau dan ook filters krijgt die invloed hebben op zowel de producten zelf als op de bijbehorende minimale prijs hebben.

En de uitleg lijkt misschien niet helemaal relevant, maar is het wel.

In de huidige situatie kunnen we domweg per product 1 cijfer voor de laagste prijs bewaren en daar heel efficient mee rekenen. Maar in dit geval moeten we alle prijzen elke keer meenemen voor het geval je de winkel die de laagste prijs hanteerde hebt uitgesloten. Het verwante geval met direct ook de laagste prijs inclusief verzendkosten is nog een stuk meer rekenwerk (waar bovenstaand verhaal wat meer op is gericht) maar is in de basis hetzelfde probleem.

Het kan tenslotte zijn dat je de goedkoopste winkel uitgesloten hebt en dan moet er een andere laagste prijs staan in de prijskolom van de productenlijst. Of het kan zijn dat je alle leveranciers van een product hebt uitgesloten en dan moet er zelfs geen prijs staan (en het product dus ook uit de lijst verdwijnen als zijnde niet leverbaar).

Het is overigens geen onwil om dit niet te faciliteren, maar domweg op diverse vlakken (zowel in de programmacode als in de interface) moeilijk om te realiseren. Althans, je wil dat zo'n uitbreiding natuurlijk niet ten koste gaat van de snelheid waarmee de filters reageren...

[ Voor 21% gewijzigd door ACM op 28-07-2013 11:10 ]

[H!GHGuY]

Ik had verwacht dat dit voornamelijk slechts iets complexere queries zou met zich meebrengen, maar blijkbaar is de structuur net iets anders.

Misschien iets om in het achterhoofd te houden tijdens refactorings, om deze use-case op termijn wel te ondersteunen.

[ACM]

H!GHGuY schreef op zondag 28 juli 2013 @ 11:39:
Ik had verwacht dat dit voornamelijk slechts iets complexere queries zou met zich meebrengen, maar blijkbaar is de structuur net iets anders.

Als iemand zo'n opmerking krijgt, heb ik altijd de neiging om uit te leggen waarom het dan niet zo simpel is. Dus bij deze een lap tekst waarin ik dat probeer

Maar je zit met allerlei dingen die er ook bij komen kijken. Sowieso moet het dan in principe voor alle plekken waar we productprijzen tonen gelden.

Denk daarbij dan onder andere aan de productlijsten ook aan:
- de producten naast nieuwsberichten/boven topics,
- de productenblokjes in BBG's,
- de nieuwprijsindicatie in V&A,
- de prijsgrafieken van producten,
- het pricewatchblokje op de frontpage,
- het blokje populaire producten op de pricewatch-portal,

Op al die - en andere - plaatsen verwacht je dan natuurlijk dezelfde "laagste prijs" te zien. Nou krijgen die over het algemeen technisch gezien op dezelfde manier hun prijs, dus dat valt op dat gebied wel mee. Maar sommige daarvan worden nu als complete html gecached, omdat ze toch voor iedereen hetzelfde zijn... Verder moeten we in de interface ook proberen duidelijk te maken dat er een filter op de prijzen is toegepast.

Het filter links van de productlijsten is nu al vrij complex en krap, als we daar ook nog op een of andere manier een lijst van (alle?) winkels en aanvullende prijsfiltering (Winkelbeoordeling? Levertijd?) willen toevoegen, dan zal het er niet zomaar overzichtelijker van worden.

Ook andere punten van aandacht zijn lastig om uit te denken/werken:
Wat moeten we doen als er geen prijzen zijn volgens jouw winkelfilter, maar er wel prijzen zijn als je dat filter niet had? Moeten we dan toch een prijs tonen? Of moet het product dan prijsloos worden, waarbij het dus onder andere wegvalt uit de productenlijsten bij categorieen?
En als we dan toch een prijs moeten tonen zal dat vast met e.o.a. toelichting moeten. Hoe doe je dat dan weer op al die alternatieve plekken waar we een prijs tonen maar er erg weinig ruimte is om duidelijk die toelichting te geven?

Een andere is: Wat als er een groot verschil zit tussen jouw voorkeurswinkels en de daadwerkelijk laagste prijs? Wil je daar dan toch wel een indicatie van zien?
Die laatste wat meer concreet: Als jij 500 euro kan besparen op een TV door een 'm bij een andere webwinkel te kopen, wil je dat wel of niet weten? Ik gok van wel
En dan gelijk de vervolgvraag: Wanneer is iets een groot verschil?

Voor de technische aspecten; onze productlijsten worden niet via SQL gegenereerd. Het zouden nu al bijzonder complexe queries zijn geworden als we de huidige listings ermee zouden proberen te genereren. Vooral voor leuke dingen als de facetaantallen (die cijfertjes tussen haakjes die aangeven hoeveel producten matchen met specificatie X).

Voor je beeldvorming en dit is dus niet bedoeld als "ooh het is zo moeilijk, want we hebben de code te ingewikkeld gemaakt...":
E.e.a. is een zelfbouwomgeving die lijkt op Solr (en Lucene), zowel op het gebield van aanroep als werking.

Kort samengevat: die laagste prijzen worden omgezet in groepen bitmaps. Hetzelfde gebeurt voor de specificaties, datum van eerste prijsvermelding, categorie, merk, serie en gemiddelde reviewscore.
Al die bitmaps worden door jou als gebruiker tijdens het filteren (of domweg door naar een bepaalde pagina te navigeren) gekozen en via bitwise-AND gecombineerd. Dat is een eenvoudige en efficiente manier om allerlei verschillende aspecten van producten te combineren. Zonder zo'n soort manier zouden we bijvoorbeeld veel meer tijd kwijt zijn aan het bepalen van de correcte facetaantallen. En met correct bedoel ik dat het rekening houdt met het feit dat een filter via AND of OR werkt of dat je al een andere optie voor dezelfde specificatie hebt aangevinkt.

Doordat je voor iedere beschikbare keuzeoptie net moet doen of de gebruiker dat facet ook echt heeft geselecteerd, heeft elke keuzeoptie in principe een eigen zoekopdracht nodig! Bij bijvoorbeeld de laptopscategorie heb je het dan momenteel over 561 facetten (als je het filter op prijsloos zet, dan worden het er zelfs 1652). Met onze aanpak is dat domweg voor elk facet een bitmap bepalen en dan per keuzeoptie zo'n bitwise-AND uitvoeren met de bitmap van die keuzeoptie.
Maar in het geval van een SQL-database zou het 561 SQL-statements nodig hebben (hoewel je bij OR-filters e.e.a. kunt samenvoegen met GROUP BY). En het zijn al niet de eenvoudigste SQL-statements om uit te voeren...

Zodra die laagste prijs per product voor elke request verschillend kan zijn is dat voor dat specifieke aspect van een product niet meer via zo'n handige bitmap mogelijk
Nou heeft onze code ook al ondersteuning voor "moeilijkere prijzen" (bijvoorbeeld voor de eenmalige kosten bij telefoons in combinatie met een abonnement), maar we proberen natuurlijk zoveel mogelijk die efficiente variant te gebruiken. Zodra je alle 80.000 producten met prijs benaderd is het handig dat zo'n prijsbereikfilter zo snel mogelijk is. Ook voor sorteren op prijs geldt dat elke complicatie die je toevoegt eigenlijk ongewenste is voor de performance

Rekening houden met refactorings is dus op zich niet nodig, maar het is dus domweg niet zo simpel als een SQL-statement uitbreiden. En dan heb je het dus nog niet eens over de interface en andere gebruikerskwesties gehad

Als je trouwens antwoorden op vragen in de tekst hebt, dan hoor ik ze graag. 't Zijn tenslotte punten waar wij invulling aan zullen moeten geven en daarbij is input van onze gebruikers alleen maar nuttig

[Yankovic]

Volgens mij maak je de oplossing een stuk ingewikkelder dan wat er wordt gevraagd.

We hebben het hier enkel over de pricewatch. Alle producten bij artikelen BBG's, V&A enz. hoeven niet gefilterd te worden op webshop, daar kan je prima de laagste prijs blijven tonen (oftewel ik hoef dit niet sitewide te willen instellen).

In de pricewatch:
- Bevat het product wel een prijs voor die webshop? Wel tonen
- Bevat het product geen prijs voor die webshop? Niet tonen

Wanneer het product wel getoond wordt vind ik het prima dat daar de laagste prijs (wat dus ook een andere webshop kan zijn) getoond wordt. Ik hoef alleen te weten dat mijn webshop dat product ook aanbied. En dan kom ik er vanzelf wel achter of het daar 500 euro duurder is of niet.

Wat betreft design: Als ik de tweakers website zo zie heb ik er alle vertrouwen in dat jullie designers wel iets leuks weten te bedenken ;-)

Ik zeg niet dat het nu ineens een stuk makkelijker voor jullie wordt. Maar ik na het lezen van bovenstaand stuk wel het idee dat jullie op zoek zijn naar een veel ingewikkeldere oplossing voor de feature die gevraagd wordt..

[ACM]

Ah, ik had die reactie nog gemist.

Een aanverwant probleem is dat de laagste prijs die je in de lijst producten ziet, niet per se bovenaan de lijst prijzen staat zodra je doorklikt naar de prijslijst van een product. En dat komt doordat we bepaalde filters en kostenberekeningen wel toepassen op de prijslijst, maar niet op de productlijst.
Als we extra filters op prijsniveau (welke winkel levert het is er zo een) bij die producten integreren, wordt het nog vreemder dat die niet overeen komen

Het zal per gebruiker verschillen of ze het logisch vinden of niet dat de laatste prijs niet overeenkomt met de winkels die daadwerkelijk voldoen aan het filter dat je hebt ingesteld.
Bij puur een filter op webwinkels kunnen we daar misschien nog wel mee wegkomen. Maar zodra we ook filters op verzendmethode, winkelscore, etc aanbieden, dan wordt het erg vreemd om toch een laagste prijs te tonen die zodra je diezelfde filters instelt op de prijspagina wel een andere laagste prijs opleveren