Script: bezoekers hebben ook deze producten bekeken

zaterdag 13 maart 2010 17:21

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Hallo,

Vaak zie je bij webwinkels een kopje: Bezoekers die deze artikelen hebben bekeken hebben ook deze artikelen gezien.

Nu ben ik al een tijdje opzoek naar een script hiervoor maar ik heb geen idee hoe dit heet dus kan ik geen goede zoekwoorden gebruiken. Ik kan het dus niet vinden. Weet iemand hoe dit heet? Of weet iemand een artikel hierover?

Groet,

Keno

zaterdag 13 maart 2010 17:24

Acties:

0 Henk 'm!

Bastiaan

Bas·ti·aan (de, m)

Ik moet eerlijk zeggen dat ik daarover ook geen idee heb.

Volgens mij werken die sites onder andere met cookies (correct me if I'm wrong). Wellicht dat je je zoekopdrachten daarmee kunt combineren?

zaterdag 13 maart 2010 17:25

Acties:

0 Henk 'm!

4Real

Dan ga je al snel naar de richting van datamining en trends daarin herkennen. Denk niet dat je daarvoor snel simpele scripts gaat vinden.

zaterdag 13 maart 2010 17:29

Acties:

0 Henk 'm!

Jermaine

Zoek eens op "recently viewed pages cookie" of iets in die richting. Voor WordPress zijn daar sowieso plugins voor, als je dat zoekt kan ik wel even in mijn archiefje graven.

zaterdag 13 maart 2010 17:30

Acties:

0 Henk 'm!

Verwijderd

Dit is meestal onderdeel van de gebruikte webshopsoftware en kun je niet simpelweg als een scriptje downloaden. Als je geen idee hebt hoe je zelf zoiets moet aanpakken kun je het beste eens gaan kijken naar een kant-en-klare webshopoplossing zoals hier opgesomd staan.

zaterdag 13 maart 2010 17:37

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Dank voor de reacties, met cookies kom je niet ver denk ik. Omdat ik dit bedoel:
Persoon X heeft 5 artikelen bekeken. Nu komt persoon Y online en bekijkt 1 van de 5. Hierbij ziet hij dus een kopje: Andere gebruikers hebben deze artikelen bekeken, en hij ziet die 5 die persoon X had bekeken. Cookies zijn client side en dit lukt dus niet. (zeg me als ik het verkeerd zie)

Bovendien zijn cookies tijdelijk en wil ik het voor altijd bijhouden, omdat na 10000 bezoekers de informatie erg nauwkeurig wordt. Dan worden er waarschijnlijk alleen maar producten weergegeven die ECHT met elkaar te maken hebben.

Ik heb al wel een opsetje gemaakt, alleen het simpele gedeelte, deze bestaat uit 3 tabellen:

producten
-product id

bezoekers:
-id
-ip

Bekeken:
-id
-ip_id
-product_id

Deze informatie wordt nu opgeslagen, alleen om de populairste producten er nu uit te halen is een (voor mij) zeer moeilijke query nodig en ik weet niet hoe dit moet. Vandaar de vraag naar een voorbeeld

zaterdag 13 maart 2010 17:38

Acties:

0 Henk 'm!

Onbekend

...

Er zal vast geen standaard script hiervoor zijn, maar volgens mij is het niet moeilijk om dat zelf te programmeren:

Maak een tabel met de kolommen:
Sessie-id (waarmee je een gebruiker kan identificeren)
Product-id (het product dus)
Datum (datum waarop het product is bekeken)

Elke keer dat een product wordt opgezocht voeg je een regel bij in de tabel.
Om de producten te laten zien die anderen hebben gezien, maak je een select query met het Product-id met een inner join met Sessie-id op dezelfde tabel.

Oude regels van een paar maanden oud kan je verwijderen omdat dat meestal niet relevant meer is. Vandaar de datum-kolom.

Succes!

Speel ook Balls Connect en Repeat

zaterdag 13 maart 2010 17:49

Acties:

0 Henk 'm!

Verwijderd

Je maakt gewoon een tabel met alle bezoeken per product. Dus gewoon ip en product_id ofzo. Vervolgens haal je met een query alle bezoekers op die het huidige product bezocht hebben. Binnen deze resultaten maak je een top 5 van de meest voorkomende product_id's en voila, je hebt de 5 producten die het meest bezocht zijn door iedereen die ook dit product bezocht heeft.

zaterdag 13 maart 2010 17:50

Acties:

0 Henk 'm!

roy-t

Ik heb ooit het zelfde probleem gehad en hier: Database structuur "Andere bezoekers bekeken ook..." een goed antwoord gegeven. Zorg er iig voor dat je geen kruistabel maakt (n x n) maar een koppel tabel met een teller (iets als a * 3, waar product a in de eerste kolom staat, kolom b in de 2e kolom, en count in de derde kolom, via een stored procedure of via iets heel simpels (laagste id altijd eerst) kun je er daarna voor zorgen dat je alleen a->b hebt en niet b<-a (niet nodig).

Verder komt dit vast ook van pas in de implementatie daar van: http://roy-t.nl/index.php...nique-transact-sqlms-sql/

@ Teunenboom, dat is veel en veel meer informatie dan die je nodig hebt.

[ Voor 5% gewijzigd door roy-t op 13-03-2010 17:51 ]

~ Mijn prog blog!

zaterdag 13 maart 2010 17:51

Acties:

0 Henk 'm!

GlowMouse

Op plan: Introductie 'vergelijkbare producten' in de Pricewatch wordt wat literatuur aangeraden.

zaterdag 13 maart 2010 18:13

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Php

Onbekend schreef op zaterdag 13 maart 2010 @ 17:38:
Er zal vast geen standaard script hiervoor zijn, maar volgens mij is het niet moeilijk om dat zelf te programmeren:

Onderschat het niet. Zeker niet wanneer je een breed assortiment hebt en/of seizoensgebonden zaken verkoopt zoals bijvoorbeeld bloemen of zelfs dingen als parfum. Iemand die vlak voor Valentijn een cadeauverpakking parfum voor zijn vriendin koopt tegelijk met nog wat andere aankopen kan dit soort intelligentere scripts al gauw de verkeerde kant op sturen waardoor het script dus zinloos wordt.

Dingen waarnaar je zal moeten kijken: relevantie (hebben de productcategorieën wat met elkaar te maken, maak dan de weging groter), actualiteit (hoe recenter, hoe hoger de weging) en volume (als meerdere mensen dezelfde dingen tegelijk bekijken/kopen, dan zal het wel relevant zijn). En dan heb ik het mogelijk lager laten wegen van bepaalde productcategorieën op basis van dagen als Valentijn en Kerst nog niet eens genoemd.

Zoals je wel kan raden: daar zijn geen standaardscripts voor, om de doodsimpele reden dat het allemaal afhankelijk is van je eigen implementatie.

[ Voor 6% gewijzigd door NMe op 13-03-2010 18:17 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

zaterdag 13 maart 2010 19:04

Acties:

0 Henk 'm!

Onbekend

...

NMe schreef op zaterdag 13 maart 2010 @ 18:13:
En dan heb ik het mogelijk lager laten wegen van bepaalde productcategorieën op basis van dagen als Valentijn en Kerst nog niet eens genoemd.

Daarmee heb je wel een punt. Ik weet niet wat voor webshop de topicstarter heeft, maar ik ging er vanuit dat ze "tijdloze" producten verkopen.

Zodra je echt ingewikkeldere verbanden wil gaan leggen die bijvoorbeeld rekening houdt met vorige zoekacties van de zelfde gebruiker (interessegebied), zal je niet genoeg hebben aan een enkele query. Maar aan de topicstart te zien hoef je daar geen rekening mee te houden.

Speel ook Balls Connect en Repeat

zaterdag 13 maart 2010 19:31

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Er zijn artikelen op mijn website die seizoens gerelateerd zijn. Echter zullen de artikelen die door de andere bezoekers ook werden bekeken in hetzelfde interesse gebied liggen?

Ik denk dat ik het niet al te moeilijk moet maken met seizoentrends. Ik zal met een simpelere versie een grote slag kunnen slaan.

De informatie van roy-t heb ik zeker wat aan! Het is met mijn ervaring in programmeren nog steeds erg ingewikkeld maar ik hoop eruit te komen. Ik zal het laten weten als het werkt. Ook zal ik dan mijn script ergens publiceren zodat het voor andere makkelijker wordt om dit te zoeken

:edit:
Okey, ik heb het nu werkend! Ik heb nog niet de bezoekers om het goed te testen maar tot nu toe ziet het er goed uit. Ik heb vooral de tips van roy-t gebruikt! Bedankt hiervoor. Ik zal even posten wat ik nu heb en graag ontvang ik commentaar tot verbeteringen

Allereerst mijn database structuur:

producten
-id
-product_id

ip
-id
-ip

bekeken
-id
-ip_id
-product_id

combinaties
-id
-product1
-product2
-teller

En de php code is:

code:

<?php
            if(isset($_GET['id'])){
                $select_product_query = mysql_query("SELECT * FROM $producten WHERE id = '".$_GET['id']."'");
                if(mysql_num_rows($select_product_query)==1){
                    $list_producten = mysql_fetch_array($select_product_query);
                    
                    $select_ip_query = mysql_query("SELECT id FROM ip WHERE ip = '".$ip."'");
                    if(mysql_num_rows($select_ip_query)==0){
                        mysql_query("INSERT INTO ip (id, ip) VALUES('', '".$ip."') "); 
                        $ip_id = mysql_insert_id();
                    } else {
                        $list_id = mysql_fetch_array($select_ip_query);
                        $ip_id = $list_id['id'];
                    }
                    
                    
                    $select_insert_bekenen_query = mysql_query("SELECT * FROM bekeken WHERE ip_id = '".$ip_id."' AND product_id = '".$list_producten['productID']."'");
                    if(mysql_num_rows($select_insert_bekenen_query)==0){
                        mysql_query("INSERT IGNORE INTO bekeken (id, ip_id, product_id) VALUES('', '".$ip_id."', '".$list_producten['productID']."') "); 
                    }
                    
                    $select_bekenen_query = mysql_query("SELECT * FROM bekeken WHERE ip_id = '".$ip_id."'");
                    while($list_bekeken = mysql_fetch_array($select_bekenen_query)){
                        if($list_bekeken['product_id'] != $list_producten['productID']){
                            $array = array($list_bekeken['product_id'], $list_producten['productID']);
                            sort($array);
                            $select_combinatie_query = mysql_query("SELECT * FROM combinaties WHERE product1 = '".$array[0]."' AND product2 = '".$array[1]."'");
                            if(mysql_num_rows($select_combinatie_query)==0){
                                mysql_query("INSERT INTO combinaties (id, product1, product2, teller) VALUES('', '".$array[0]."', '".$array[1]."', '1') "); 
                            } else {
                                mysql_query("UPDATE combinaties SET teller=teller+1 WHERE product1 = '".$array[0]."' AND product2 = '".$array[1]."'");
                            }
                        }

                    }
                    
                    $select_populairste_query = mysql_query("SELECT *,SUM(teller) AS total_weight FROM combinaties WHERE (product1 = '".$list_producten['productID']."' OR product2 = '".$list_producten['productID']."') GROUP BY product1, product2 ORDER BY total_weight DESC LIMIT 5");
                    while($select_populairste = mysql_fetch_array($select_populairste_query)){
                        if($select_populairste['product1'] == $list_producten['productID']){
                            $product = $select_populairste['product2'];
                        } else {
                            $product = $select_populairste['product1'];
                        }
                        //echo $product."<br>";
                    }
//hieronder wordt het product weergegeven!
}
}
?>

[ Voor 71% gewijzigd door Verwijderd op 13-03-2010 21:41 ]

donderdag 18 maart 2010 20:03

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Update:
Na 4 volledige dagen te hebben gedraaid heb ik dit script weer stilgezet.
Mijn database kent 4871 producten.
Er zijn in totaal 16 verschillende ip's op mijn website geweest, waaronder mijn ip en een aantal google ip's (4 of meer)
Totaal zijn er dan 1124 artikelen bekeken (google heb ik nogal aan het werk gezet en bekijkt veel)
De tabel combinaties heeft maar liefst 91.832 combinaties gedetecteerd. En dit in maar 4 dagen zonder bezoekers.

Oftewel. Deze manier van werken is niet juist. Heeft iemand een idee hoe dit wel werkt?

donderdag 18 maart 2010 20:15

Acties:

0 Henk 'm!

Verwijderd

Dan moet je er in ieder geval voor zorgen dat op 't moment dat google op je site komt, het script niet gedraaid wordt.

donderdag 18 maart 2010 20:30

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Dit zal niks uitmaken. Google heeft nog niet eens 1/4 geindexceerd, en de database is al overspoeld.

Natuurlijk zal google (e.d.) er uit moeten om redenen dat google geen relevante artikelen bezoekt maar gewoon alles en hierdoor niks bijdraagt aan de resultaten. Google moet er niet uit om redenen dat het systeem het niet aan kan. Als er ooit 1 bezoeker komt die alles doorspit hoort niet meteen de database vol te zitten.

Google heb ik er nog bijzitten omdat dit makkelijk test, en anders was ik nu nog niet op dit probleem gelopen

[ Voor 12% gewijzigd door Verwijderd op 18-03-2010 20:31 ]

donderdag 18 maart 2010 20:44

Acties:

0 Henk 'm!

Verwijderd

Sowieso is het niet handig om bij elk artikel die weergeven wordt een nieuwe rij aan te maken. Wat mij een idee lijkt is om per combinatie het aantal keer dat het weergeven is aangegeven wordt, dit in combinatie met de sessie. Dus als een bezoeker in één sessie 20 producten bekijkt, wordt de combinatie gemaakt tussen al deze artikelen met daarbij een aantal, bij de eerste bezoeker zal dit 1 zijn (goh).

Zodra er meer bezoekers komen krijg je wel een flinke database, maar daar ontkom je niet aan, als elk artikel met elkaar gekoppeld zou zijn, gaat het om zo'n 23 miljoen rows, maar dat zal niet zo heel snel voorkomen... Maar denk dat een beetje database dat wel moet kunnen handlen.

Ik weet het ook niet, 't is maar wat ik hier terplekke bedenk.

edit: Ah, wacht eens, rekenen blijft moeilijk... Je gaat producten niet dubbel aan elkaar koppelen natuurlijk, dus je komt een heel stuk lager uit dan de 23 miljoen, de helft of zo in het uiterste geval?

Kan me niet voorstellen dat een moderne database daar, mits het goed geïndexeerd is e.d., van gaat zweten (want db's kunnen niet zweten

).

[ Voor 19% gewijzigd door Verwijderd op 18-03-2010 20:54 ]

donderdag 18 maart 2010 20:51

Acties:

0 Henk 'm!

roy-t

Exact wat Guidoh zegt, je haalt nu op hoevaak het bekeken is met count. Maar ik had je een linkje gegeven met een manier om een query alleen uit te voeren als deze nog niet voorkwam in de database. (Als dat wel zo is moet je updaten en hit = hit+1 doen).

Dat of er zit ergens anders een foutje.

~ Mijn prog blog!

donderdag 18 maart 2010 20:55

Acties:

0 Henk 'm!

Hipska

Hoezo je DB is overspoeld? Je hebt nog maar 91 000 records

Als je DB overspoeld is met dit (voor DB) lage aantal records is er volgens mij iets mis met je Data Model. Daarom plaats ik hier enkele tips:

Bij de tabellen bekeken en combinaties kan het veld 'id' gewoon weggelaten worden als je een UNIQUE legt op de andere id velden. (bespaart je weer een in dit geval onnodige INT of BIGINT)
In de tabel combinaties kan je dubbele gegevens krijgen:

code:

+-------+-------+----+
| 10047 | 10058 | 15 |
| 10034 | 10047 | 23 |
| 10058 | 10047 |  6 |
+-------+-------+----+

Op deze manier kan je bijvoorbeeld dubbel zoveel rijen hebben dan eigenlijk nodig. Probeer ervoor te zorgen dat de eerste kolom altijd de hoogste (of laagste) waarde bevat.

En maak je echter geen zorgen als een tabel in je DB een aantal records krijgt met een aantal nulletjes achter, daarvoor is zo'n ding net ontworpen.

donderdag 18 maart 2010 21:02

Acties:

0 Henk 'm!

Verwijderd

Hipska schreef op donderdag 18 maart 2010 @ 20:55:
Hoezo je DB is overspoeld? Je hebt nog maar 91 000 records
Als je DB overspoeld is met dit (voor DB) lage aantal records is er volgens mij iets mis met je Data Model. Daarom plaats ik hier enkele tips:

Bij de tabellen bekeken en combinaties kan het veld 'id' gewoon weggelaten worden als je een UNIQUE legt op de andere id velden. (bespaart je weer een in dit geval onnodige INT of BIGINT)
In de tabel combinaties kan je dubbele gegevens krijgen:
code:
1
2
3
4
5
+-------+-------+----+
| 10047 | 10058 | 15 |
| 10034 | 10047 | 23 |
| 10058 | 10047 |  6 |
+-------+-------+----+
Op deze manier kan je bijvoorbeeld dubbel zoveel rijen hebben dan eigenlijk nodig. Probeer ervoor te zorgen dat de eerste kolom altijd de hoogste (of laagste) waarde bevat.

En maak je echter geen zorgen als een tabel in je DB een aantal records krijgt met een aantal nulletjes achter, daarvoor is zo'n ding net ontworpen.

Inderdaad, een database kan wel wat hebben, maar om de performance zo hoog mogelijk te houden zou je even moeten kijken wat het gunstigste is. Verder moet ik zeggen dat ik er niet aan had gedacht om het op die manier op te lossen (eerste veld hoogste waarde), die ga ik zeker onthouden.

Aangezien je volgens mij wel een PK nodig hebt in je tabel, is het misschien een optie om de 2 velden daarvoor te gebruiken? Moet zeggen dat ik dat ik niet zo vaak gebruik maak van dubbele PK's, dus het zou kunnen dat dit niet het gewenste resultaat op levert qua performance.

donderdag 18 maart 2010 21:33

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Bedankt voor de snelle reacties!

@Hipska: Ja, dat noem ik overspoeld na 4 dagen zonder dat je kan zeggen dat er uberhaupt bezoekers zijn geweest.

@roy-t: Ik heb je linkje gelezen en opgevolgd. Inderdaad een slimme oplossing en ik heb deze ook erbij zitten:

code:

$array = array($list_bekeken['product_id'], $list_producten['productID']);
sort($array);
En mocht hij al bestaan telt hij er al 1 bij op ipv een nieuwe INSERT:
mysql_query("UPDATE combinaties SET teller=teller+1 WHERE product1 = '".$array[0]."' AND product2 = '".$array[1]."'");

Is het echt zo dat een database 11520000 records makkelijk aan kan zonder echt langzaam te lopen? En hierin te zoeken en updaten?
Ik merkte al (of dit kan toeval zijn) dat de website langzaam begon te lopen door het script. Ik denk dat het hierdoor kwam: Google bezocht zijn 1000ste artikel en hierdoor gaat het script kijken welke artikelen hij hiervoor had bekeken. Hiermee voegt het script 1000 nieuwe rijen toe of verandert hij deze.

Ik zit nu zelf te denken aan een andere oplossing. Echter mijn google skills schieten weer te kort tot dusver

Als ik nu het hele idee van de tabel van combinaties laat schieten en het houd bij de tabel "bekeken". En daarna een gecombineerde query gebruiken om de informatie eruit te halen. De informatie die nodig is zit hier namelijk al in.
Selecteer alle mensen die hetzelfde product hebben bekeken:
Select ip_id from bekeken where product_id = $product

En nu de top 5 andere producten selecteren:
Select COUNT(*) from bekene where ip_id = $ip_id

Zoiets:

code:

$select_bekenen_query = mysql_query("SELECT * FROM bekeken WHERE product_id = '".$list_producten['productID']."'");
while($list_bekeken = mysql_fetch_array($select_bekenen_query)){
    $select_bekenen2_query = mysql_query("SELECT * FROM bekeken WHERE ip_id = '".$list_bekeken['ip_id']."'");   
}

Alleen nu in 1 query, maar ik weet de term hiervoor niet om dit te googlen
:edit: codetags, excuses

donderdag 18 maart 2010 21:41

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Php

"Subquery" of "join".

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

donderdag 18 maart 2010 21:44

Acties:

0 Henk 'm!

Verwijderd

Om te beginnen moet ik zeggen dat je post erg onleesbaar is zonder code-tags.

Daarnaast is het niet slim om een tabel van de mensen bij te houden, want zo krijg je een grotere database dan dat er nodig is. Imho is zoiets een redelijke oplossing (zoals al eerder gezegd door zowel mij als andere user):

code:

+----------+----------+-------+
| productA | productB | count |
+----------+----------+-------+
|      456 |     8374 |   887 |
|     1235 |     4324 |    12 |
|     4958 |     8548 |   434 |
+----------+----------+-------+

Vervolgens in de sessie artikelen bijhouden die recent bekeken zijn, hierbij kan je ook kiezen om bijvoorbeeld er max. 10 te onthouden, waardoor artikelen die heel vroeg in de sessie bekeken worden niet meer opgenomen worden hierin. Per nieuw artikel die je bekijkt, kan je dan een rij in de table aanmaken/updaten. Het ophalen is dan vrij simpel, door te sorteren op "count".

edit: Ga er vanuit dat je MySQL gebruikt?

vrijdag 19 maart 2010 08:41

Acties:

0 Henk 'm!

roy-t

Oh btw je hebt 5000 pruduct, je kunt dus nooit meer dan 25.000.000 rijen gaan krijgen in je product. En met de oplossing die ik en GuidoH en andere aandragen zal het toch minder moeten zijn. En ja GoogleBot is evil!

~ Mijn prog blog!

vrijdag 19 maart 2010 09:21

Acties:

0 Henk 'm!

GlowMouse

Verwijderd schreef op donderdag 18 maart 2010 @ 21:33:
Is het echt zo dat een database 11520000 records makkelijk aan kan zonder echt langzaam te lopen? En hierin te zoeken en updaten?

Dat ligt er helemaal aan wat voor queries je erop loslaat. Een SELECT COUNT(*) die in de loop der tijd steeds meer rijen moet lezen om het aantal te bepalen, gaat niet blij zijn met je 11M records. Bij (productA,productB,count) kun je met één goede multi-column index de performance erg goed krijgen.

vrijdag 19 maart 2010 10:13

Acties:

0 Henk 'm!

Matis

Rubber Rocket

roy-t schreef op vrijdag 19 maart 2010 @ 08:41:
Oh btw je hebt 5000 pruduct, je kunt dus nooit meer dan 25.000.000 rijen gaan krijgen in je product. En met de oplossing die ik en GuidoH en andere aandragen zal het toch minder moeten zijn. En ja GoogleBot is evil!

Ja, die 25M is het maximale aantal, maar ik verwacht dat je een aantal Clouds krijgt waarin gebruikers artikelen zoeken. Ik weet niet wat de TS aanbiedt, maar je zou kunnen indenken dat mensen die opzoek zijn naar levensmiddelen niet gaan kijken bij de auto-onderdelen etc.

Dat neemt niet weg dat ik dit een reuze interessant topic vind en ook de achterliggende gedachte van data-mining

If money talks then I'm a mime
If time is money then I'm out of time

vrijdag 19 maart 2010 14:33

Acties:

0 Henk 'm!

Verwijderd

Als mensen op je site zitten om levensmiddelen te kopen, terwijl je auto-onderdelen verkoopt, dan zit er iets niet helemaal goed, gok ik dan...

Maar 25M zou het maximale aantal zijn als je de koppelingen dubbel opslaat, dat doe je uiteraard niet, dus dan komt het maximale op zo'b 12,5M.

Vind dit inderdaad ook een erg interessant topic, had er nog nooit over na gedacht... Toch maar eens voorstellen om iets dergelijks ook in onze shop te implementeren.

zaterdag 20 maart 2010 17:21

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

Bedankt allemaal voor de reacties, ik ben weer verder gekomen met jullie tips.

Allereerst ben ik de combinaties weer gaan gebruiken omdat jullie hadden gezegt dat de database dit met gemak aan moest kunnen! En meteen werd de website weer langzaam (Paar seconden wachten). Hierna heb ik de kolom ID verwijdert en de primairy key op product1 en product2 gezet! En raad eens: Super snel! Geen vertraging te merken. Verwonderlijk hoeveel dit verschil maakt. Dank jullie

Het voordeel om sessions te gebruiken om artikelen in te laten staan zie ik nog niet helemaal? Ik gebruik nu wel sessions om gebruikers met een dynamic ip op te sporen en zo dezelfde ID te laten houden. De artikelen die hij bekijkt worden nog steeds in de database opgeslagen met zijn session id. Door middel van een cronjob worden alle records geleegd die ouder zijn dan X dagen. Hiermee worden artikelen die de bezoeker nu nog bekijkt niet meer gekoppeld aan artikelen die hij X dagen eerder bekeek.

Hiervoor gebruik ik nu 3 maanden om eerst zo veel mogelijk data te generegen. Als ik klaar ben leeg ik de database toch eerst en zal ik denk ik kiezen voor 1 maand? Hebben jullie suggesties over een bewaartijd? En waarom dan zo lang/kort?

Als laatste ben ik ook bezig met iets wat zoekmachines kan herkennen om hiervoor het script niet uit te voeren. Deze lijst heb ik uit phpBB 3.1 gestolen

. Ook zal ik het zo maken dat ik ip's kan toevoegen om mijzelf te blokkeren. Ik zal ook geen artikelen bekijken die met elkaar te maken hebben.

Ik vraag mij trouwens af of ik de titel en beschrijving wel moet meenemen in een ranking. Het lijkt mij juist beter om dit niet te doen om zo onverwachte combinaties te krijgen. Bijvoorbeeld: Als jij een autoradio koopt wil je er misschien ook boxen bij. Er zullen weinig woorden overeenkomen tussen deze artikelen maar ze hebben veel met elkaar te maken. Dit voorbeeld is wel duidelijk, maar het is juist leuk om onverwachte combinaties naar voren te laten komen. Om gebruikers iets te laten zien waar ze zelf misschien nog niet aan hebben gedacht.

@GuidoH: wacht dan even tot ik hiermee klaar ben, dan kan je de code krijgen

zaterdag 20 maart 2010 17:46

Acties:

0 Henk 'm!

Verwijderd

Verwijderd schreef op zaterdag 20 maart 2010 @ 17:21:
Bedankt allemaal voor de reacties, ik ben weer verder gekomen met jullie tips.

Allereerst ben ik de combinaties weer gaan gebruiken omdat jullie hadden gezegt dat de database dit met gemak aan moest kunnen! En meteen werd de website weer langzaam (Paar seconden wachten). Hierna heb ik de kolom ID verwijdert en de primairy key op product1 en product2 gezet! En raad eens: Super snel! Geen vertraging te merken. Verwonderlijk hoeveel dit verschil maakt. Dank jullie

Kijk eens aan, ik had al een vermoeden dat dat beter zal zijn.

Het voordeel om sessions te gebruiken om artikelen in te laten staan zie ik nog niet helemaal? Ik gebruik nu wel sessions om gebruikers met een dynamic ip op te sporen en zo dezelfde ID te laten houden. De artikelen die hij bekijkt worden nog steeds in de database opgeslagen met zijn session id. Door middel van een cronjob worden alle records geleegd die ouder zijn dan X dagen. Hiermee worden artikelen die de bezoeker nu nog bekijkt niet meer gekoppeld aan artikelen die hij X dagen eerder bekeek.

Als ik in een webshop zit waar ik veel artikelen bekijk, is de kans groot dat het eerste product dat ik bekijk, niks te maken heeft met het 30e product. Maar ik denk dat het uiteindelijk niet zo heel veel uit maakt, maar ik weet niet of het handig is om bij elke keer dat een artikel geopend wordt ineens 100 queries uit te voeren.

Al helemaal verdeeld over meerdere dagen zou ik niet doen, ik zou het in ieder geval laten bij de artikelen die hij in een huidige sessie bekijkt. Het is namelijk imho niet goed om aan te nemen dat een artikel, dat iemand een paar dagen geleden bekeken heeft, te maken heeft met een artikel die hij dagen erna bekijkt.

Hiervoor gebruik ik nu 3 maanden om eerst zo veel mogelijk data te generegen. Als ik klaar ben leeg ik de database toch eerst en zal ik denk ik kiezen voor 1 maand? Hebben jullie suggesties over een bewaartijd? En waarom dan zo lang/kort?

Zolang je er voor zorgt dat de rijen verwijderd worden zodra het gekoppelde artikel verwijderd wordt (mbv FK's), zie ik niet zo heel veel reden om data te gaan verwijderen, dan moet je elke keer weer opnieuw alle data verzamelen. Volgens mij wordt de data alleen maar "betrouwbaarder" naar mate je het script langer hebt draaien, maar ik kan het mis hebben hoor, heb nog geen ervaring met dergelijke zaken.

Ik vraag mij trouwens af of ik de titel en beschrijving wel moet meenemen in een ranking. Het lijkt mij juist beter om dit niet te doen om zo onverwachte combinaties te krijgen. Bijvoorbeeld: Als jij een autoradio koopt wil je er misschien ook boxen bij. Er zullen weinig woorden overeenkomen tussen deze artikelen maar ze hebben veel met elkaar te maken. Dit voorbeeld is wel duidelijk, maar het is juist leuk om onverwachte combinaties naar voren te laten komen. Om gebruikers iets te laten zien waar ze zelf misschien nog niet aan hebben gedacht.

Ik verwacht dat je dat voor zoekmachines bedoelt. Ten eerste betwijfel ik of het echt iets is waar mee je in de zoekmachines gaat scoren. Als dat het geval is, dan zal het waarschijnlijk wel goed gaan komen als je de naam van het product terug laat komen (niet te vaak).

@GuidoH: wacht dan even tot ik hiermee klaar ben, dan kan je de code krijgen

Bedankt voor het aanbod, maar ik moet hem afslaan.

zaterdag 20 maart 2010 18:03

Acties:

0 Henk 'm!

Verwijderd

Topicstarter

@ meerdere dagen bewaren:
Ik denk juist van wel, meestal komen mensen op je website voor maar 1 ding. Ze bekijken het, willen het de dag erna nog eens zien. Of even laten zien aan andere. Erover nadenken. En misschien na een tijdje pas kopen. Of ze zoeken meerdere shops af en komen later weer terug? Ik denk dat het juist over meerdere dagen bewaard moet worden. Maar uiteraard zal dit product afhankelijk zijn.

@data verwijderen
Ik heb het over de data uit bekeken, vergelijkbaar met jou session idee.
De combinaties worden ten alle tijden bewaard natuurlijk! Deze informatie verdwijnt nooit!

@
Nee, daarmee bedoel ik niet de zoekmachines. Daarmee bedoel ik de bezoekers zelf. Voor de zoekmachines zal het je ranking naar beneden halen omdat er verschillende dingen op 1 pagina staan. Voor bezoekers zal dit juist goed zijn.

Onderwerpen