woensdag 17 oktober 2012

Vraag toestemming voor cookies van Google Analytics

Eenvoudig cookie-toestemmings-script voor Google Analytics

Enorm veel webshops en andere websites maken gebruik van cookies om de website aan te sturen, winkelwagentjes te vullen, enzovoorts. Handige en noodzakelijke cookies dus.
Maar heel veel site gebruiken ook Google Analytics. En de cookies die Google Analytics op de computer van je websitebezoeker installeert, die zijn niet persé noodzakelijk voor het goed functioneren van je website.

Nu is er sinds 5 juni 2012 een wettelijke verplichting in Nederland om bezoekers de keus te geven of ze cookies van onder andere Google Analytics willen accepteren. En die wet verplicht iedere (ja, iedere) website aan de bezoeker expliciet toestemming te vragen voor het plaatsen van die niet-noodzakelijke cookies. Dat geldt dus ook voor jouw website, als je daar Google Analytics op geïnstalleerd hebt.
Je website zal je dus moeten aanpassen om expliciet toestemming te krijgen van je bezoekers voor het plaatsen van de Google Analytics cookies.

Hierbij een oplossing die je simpel in je website kunt toepassen om de toestemming voor de cookies van Google Analytics te regelen.

Met dit script kan de bezoeker van je website eenvoudig aangeven of hij wél of geen toestemming geeft om de niet-essentiële cookies van Google Analytics te accepteren. Google Analytics wordt alleen opgestart indien er wel toestemming is gegeven. De gebruiker kan op ieder moment met 1 klik de cookie-instelling wijzigen.

Het script werkt in principe in alle websites. Dus ook in je Joomla, Wordpress of welk ander CMS je ook gebruikt. En dus ook in VirtueMart en andere webshops!

Het script kan ook simpel worden uitgebreid naar andere niet-persé-noodzakelijke cookies op je website, maar ik denk dat heel veel sites alleen de Google Analytics cookies hoeven te 'regelen'.

 

Downloaden en installeren

Download het volgende bestandje en sla het op in een map op je webserver met de naam 'js' *:
cookie-permissie.js

Vervolgens plak je de volgende code in de head van je webpagina(s), bijvoorbeeld vlak voor de afsluitende </head>-tag:

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script src="js/cookie-permissie.js" type="text/javascript"></script>
<script type="text/javascript">
if (getCookie('_paqqa') == 'allow')
{
  var _gaq = _gaq || []; _
  gaq.push(['_setAccount', 'JOUW-GOOGLE-ID']);
 _gaq.push(['_gat._anonymizeIp']);
 _gaq.push(['_trackPageview']);
 (function()
 {
   var ga = document.createElement('script');
   ga.type = 'text/javascript';
   ga.async = true;
   ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') +      
   '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0];
   s.parentNode.insertBefore(ga, s);
 })();
}
</script>

Let op:
De eerste regel in bovenstaande code is een aanroep naar jQuery. Nu gebruiken veel websites al jQuery en is het dus goed mogelijk dat in de head van jouw website de aanroep naar jQuery al gedaan wordt. Als dat zo is, dan even de jQuery-regel uit bovenstaande code verwijderen. Dat voorkomt conflicten.

(*) In plaats van de map 'js' kan je natuurlijk ook een andere map gebruiken. Zorg dan wel dat je die map-naam in de derde regel van bovenstaande code aanpast.

 

Werkt het?

Als alles goed is ben je nu al bijna klaar. Vul alleen in het bovenstaande script nog even je eigen Google-Analytics-ID in, anders worden je statistieken niet bijgehouden.
Let op: de cookie-instelling bovenin je scherm zie je slechts één keer, namelijk de eerste keer dat je de pagina bezoekt. Zo wordt je bezoeker dus niet bij ieder bezoek lastig gevallen door de opvallende cookie-keuzemogelijkheid bovenin het scherm. Onderaan de webpagina blijft wél altijd de keuzemogelijkheid staan. Precies zoals de Nederlandse wetgever het graag wil dus.

Werkt het niet?

Wanneer je alles goed geïnstalleerd hebt zou je bovenin óf onderin je webpagina's voortaan een mogelijkheid moeten zien om de cookie-instelling te veranderen. Zie je dat niet, dan is er iets nog niet goed gegaan. Als het script niet lijkt te werken controleer dan of je het javascript-bestandje hebt geplaatst in de map 'js'. Als die map nog niet bestaat, moet je die eerst even aanmaken.


Waarom is dit script nou zo handig?

Er zijn online veel vergelijkbare oplossingen te vinden voor de cookie-wetgeving. Veel daarvan hebben het nadeel dat ze, iedere keer als een webpagina wordt geladen, verbinding maken met een andere server dan die van jou, omdat ze daar de scripts vanaf moeten halen. Dat is slecht voor de snelheid van je website. Je hebt bovendien geen invloed op hoe de opmaak van de cookie-venstertjes eruit ziet. En de installatieprocedure is soms nogal ingewikkeld (..). 
Mijn script draait op je eigen webserver, en de opmaak van de vensters kan je 100% zelf instellen. Hetzij met je eigen css-sheet, óf door het aanpassen van de opmaakinstellingen in het script zelf. Lekker snel dus, en lekker makkelijk.


Waarom is dit script nou zo ónhandig?

Het is bekend dat heel veel mensen, als ze de vraag gesteld wordt, géén expliciete toestemming geven voor het plaatsen van niet-essentiële cookies. Meer dan 90% zelfs zou het weigeren. En dat vinden veel webmasters niet leuk omdat ze dan veel minder informatie krijgen van hun Google Analytics account.
Daarom wordt door webmasters vaak een variant gebruikt waarbij de bezoeker van de website wel wordt geïnformeerd over het gebruik van de cookies, maar niet expliciet om toestemming wordt gevraagd.
Mijn script werkt volgens het principe van expliciete toestemming. Met een klein beetje kennis van javascript pas je het echter snel aan naar een versie die werkt volgens het principe van niet-expliciete toestemming.

Disclaimer

Iedere eigenaar van een website is zelf verantwoordelijk voor de inhoud van zijn website. Ik bied deze oplossing voor de cookie-wetgeving aan, maar accepteer geen enkele verantwoordelijkheid voor wat je ermee doet. De software is naar eer en geweten gemaakt en voldoet naar mijn idee aan de nieuwe wetgeving. Maar ik zal nooit en te nimmer aansprakelijkheid accepteren voor welke schade dan ook, ontstaan uit het gebruik van mijn software. "As is", noemen ze dat in goed engels. En voel je volledig vrij de software te gebruiken voor je eigen websites, commercieel of niet.

donderdag 27 september 2012

AjaxClickSensor:

Eenvoudig clicks op je webpagina's registreren


Wat is de AjaxClickSensor?
De AjaxClickSensor is een eenvoudig php-script in combinatie met javascript/jQuery dat clicks op een pagina registreert en meldt aan de beheerder of SEO-manager van een website.

Een 'onClick'-event handler wordt gekoppeld aan een willekeurige link op een webpagina. Wanneer de link door een bezoeker wordt aangeklikt dan wordt middels een ajax-aanroep een emailbericht gestuurd naar de beheerder van de website zodat hij weet cq meet dat die betreffende link is geklikt.


Wanneer is deze clicksensor handig?
De AjaxClickSensor kan je op diverse manieren toepassen.
Bijvoorbeeld wanneer je voor SEO-doeleinden wil weten hoe vaak op een bepaalde link is geklikt. Handig bijvoorbeeld bij email-links (<a href="mailto:..) want die worden door Google Analytics niet gemeten.
Maar ook is dit handig bij de tegenwoordig steeds vaker voorkomende 'one-page design'-websites. Die one-page websites reageren wel op clicks van gebruikers, maar laden dan geen nieuwe html-pagina. Analyseprogramma's als Google Analytics zullen die clicks dus ook niet noteren. Een website eigenaar die geïnteresseerd is in het clickgedrag van de bezoekers kan met de AjaxClickSensor alsnog over die informatie gaan beschikken en kan er gebruik van maken om bijvoorbeeld de usability te verbeteren of ten behoeve van de SEO.

Een andere mogelijke toepassing is voor de zogenaamde anchor-links in de html. Een link dus die verwijst naar een anchor-tekst binnen dezelfde webpagina. Ook clicks op die links kan je simpel meten met de AjaxClickSensor. Bijvoorbeeld wanneer je een faq-pagina hebt met 'veelgestelde vragen en antwoorden'. De AjaxClickSensor maakt het erg simpel om er achter te komen welke vraag & antwoord het meest door de bezoekers van die pagina is gelezen.

Wanneer is de clicksensor niet handig?
De AjaxClickSensor is deels een javascript toepassing en werkt dus niet bij gebruikers die javascript in hun browser hebben uitgeschakeld.

Uitbreidingsmogelijkheden
De AjaxClickSensor is in dit voorbeeld gekoppeld aan de onClick event handler. Natuurlijk kan je er ook een andere event handler aan hangen, zoals onSubmit(), onBlur(), onChange(), onLoad(), … enzovoorts.

In dit voorbeeld is de actie die de AjaxClickSensor uitvoert eenvoudig: het stuurt een emailbericht naar de beheerder van de website met daarin de boodschap dat er een click is geregistreerd.
Maar je kunt er natuurlijk ook andere dingen mee doen. Zoals het registreren van de click in een database ten behoeve van je bezoekersstatistieken bijvoorbeeld.

Ook zou je alle clicks op alle links op je pagina's op deze manier kunnen registreren. Je legt daarmee dan feitelijk de basis voor een systeem waarin je de bezoekersstatistieken van je complete site kunt gaan bijhouden. Je eigen Google Analytics dus.. zonder dat je ook maar iets met Google te maken hebt. Interessant, gezien de huidige wetgeving rond privacy en cookies.

En zo zou je nog wel andere dingen kunnen bedenken.. Automatisch tweets.. automatische Facebook-updates.. registreren van advertentie-clicks..

Doe er je voordeel mee!

Wat zijn de vereisten?
Om de AjaxClickSensor te kunnen gebruiken moet jouw hosting-provider php ondersteunen.
Dat doen ze allemaal voor zover ik weet, dus eigenlijk zou het altijd moeten werken.


Installatiehandleiding:
Maak op de server in de www-map van je website een map 'ajax' aan en plaats daarin een bestandje met als naam acs.php. De volgende php-code plaats je in dat bestand:

<?php
/**
* @file acs.php (Ajax Click Sensor)
* @param $txt : bevat de linktekst (string)
* @param $src : bevat de url van de aanroepende pagina, of null (string)
* @const GEADRESSEERDE : emailadres van de persoon waar de clickmelding naartoe gemaild moet worden
* @author Paul van Eck (www.paulvaneck.nl)
* Dit script ontvangt minimaal 1 en maximaal 2 parameters van een aanroepend programma en stuurt een
email-bericht naar GEADRESSEERDE
*/

if (isset($_POST['param_1'])) $txt = $_POST['param_1']; else $txt='ajax/acs.php aanroep zonder parameter 1.';
if (isset($_POST['param_2'])) $src = $_POST['param_2']; else $src='Onbekend.';

if (isset($_POST['param_1'])) {
// alleen verder gaan als tenminste parameter 1 is gestuurd
define('GEADRESSEERDE','jouwemail@jouwdomein.nl');

$to=GEADRESSEERDE;
$subject = $txt;
$message = $txt."\n";
$message .= $src."\n\n";
$message .= "Tijd: ".date('Y-m-d H:i:s')."\n";
$message .= "Einde bericht.\n\n\n";
$fromEmail=GEADRESSEERDE;
$headers = "From: ".$fromEmail . "\r\n" .
"Reply-To: ".$fromEmail . "\r\n" .
"X-Mailer: PHP/" . phpversion();
$resultaat=mail($to, $subject, $message, $headers);
}

if ($resultaat) $antwoord="1"; else $antwoord="0";
// 1 = email goed verstuurd, 0 = email niet goed verstuurd
echo $antwoord;
?>

Let er op dat je de waarde van GEADRESSEERDE goed invult. Vervang in het script dus jouwemail@jouwdomein.nl door je eigen emailadres, anders raakt er iemand bij jouwdomein.nl gestrest..

Vlak voor de afsluitende tag </head> in je html-document (je webpagina dus) plaats je vervolgens het volgende stukje javascript:

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>

<script type="text/javascript">
/** @author: Paul van Eck (www.paulvaneck.nl)
*/
function ajaxClickSensor(tekst)
{
var p1 = tekst;
$.ajax(
{
url: "http://www.mijnwebsite.nl/ajax/acs.php",
type: "POST",
data: {
param_1: tekst,
param_2: 'www.mijnwebsite.nl.'
}
});
return true; // zodat de standaard-functie van de link gewoon wordt uitgevoerd.
}
</script>

Hier moet je even de tekst www.mijnwebsite.nl wijzigen naar domeinnaam van jouw eigen website.
De AjaxClickSensor verstuurt 2 parameters. Parameter 1 is de tekst die door de click-sensor gemaild moet worden. Parameter 2 bevat de url van de aanroepende pagina.

In de body van je html-pagina kan je nu aan iedere willekeurige link de AjaxClickSensor hangen met de javascript event handler 'onClick()'. Hier een voorbeeld dus van een email-link:

<a onClick="ajaxClickSensor('Email-link geklikt op de contactpagina.')" href="mailto:mijnemail@mijndomein.com">Email mij!</a>

Natuurlijk kan je ook andere event handlers gebruiken zoals onMouseOver(), onSubmit() enzovoorts.

Hiermee is de installatie al compleet en zou het moeten werken.


Copyright?
Dit script mag je van mij vrij gebruiken in al je projecten, commercieel of privé. Pas hem aan waar je wilt en doe er iets goeds mee.

En even dit nog..
Nog een opmerking over de veiligheid van het php-script: Dit voorbeeld is eenvoudig gehouden om de werking van het script goed te kunnen laten zien. Wanneer je het script toepast denk dan altijd even na over het controleren van de aan het php-script doorgegeven parameters. Zeker wanneer je door het php-script database-bewerkingen laat uitvoeren is een goede controle van de invoerparameters vereist!

woensdag 12 september 2012

Captcha's? Alleen als het écht niet anders kan.

Het gebruik van captcha's is de laatste jaren in een grote stroomversnelling gekomen. Je ziet ze bijna overal. Naar mijn mening zijn ze een vervelend onderdeel van een online formulier en moet het gebruik ervan vermeden worden tenzij het écht niet anders kan. Er zijn goede alternatieven.

Wat zijn captcha's?

Captcha's, je kent ze wel, die blokjes met vervormde letters of cijfers aan het eind van online formulieren. Die letters of cijfers moet je dan foutloos na-typen en pas daarna kan je je bij een website aanmelden als klant, of als lid van een forum of zo. Maar ook heel vaak om een contactformulier te 'beveiligen' bijvoorbeeld.
Captcha's worden erg veel toegepast en ook op heel veel kleine websites zie je ze. De bedoeling van zo'n captcha is dus te voorkomen dat spammers en spambots toegang krijgen tot fora, of dat de eigenaar van de website wordt overladen met spam-emails.

Captcha's kosten je klanten

Captcha's werken, technisch gezien, meestal prima. Maar ze hebben ook enkele grote nadelen. En die nadelen komen er vrijwel allemaal op neer dat je als bedrijf met je website een barrière opwerpt voor je klanten. Het lezen van de letters of cijfers in een captcha is vaak lastig, zeker wanneer er ook nog onderscheid gemaakt wordt in hoofdletters en kleine letters (nog afgezien van het feit dat blinden en slechtzienden bijna onmogelijk met captcha's overweg kunnen).

Regelmatig zal de websitebezoeker dus geïrriteerd raken wanneer hij (of zij) een captcha tegenkomt. Waarom zou hij überhaupt die letters willen lezen en intypen? Wanneer de klant in de echte wereld voor de winkel staat zit de deur toch ook niet op slot? Als een potentiële klant je belt dan vraag je toch ook niet als eerste of hij wel serieus geïnteresseerd is in je product? Waarom dan wel online?

Een captcha is naar mijn idee een vervelende onderbreking. En elke onderbreking is, hoe je het wendt of keert, een moment waarop de potentiële klant kan afhaken. Of op z'n minst een heel klein beetje geïrriteerd raken. Captcha's kosten je dus klanten.

"Maar ik krijg zonder captcha's zoveel spam-mails .."

Dat valt in de meeste gevallen wel mee, is mijn ervaring. Láten het er per dag een stuk of 5 zijn. Wat dan nog? Voor de meeste kleinere websites zal het probleem echt niet groter zijn dan dat. Die mails gooi je gewoon in de prullenbak, toch? Volgens mij is dat een betere tactiek dan je échte klanten met een captcha op te zadelen.

Ik geloof stellig dat het opwerpen van wélke barrière dan ook uiteindelijk klanten zal kosten. Iedere website-eigenaar zal dus moeten afwegen welk soort beveiliging hij wil toepassen op de in zijn websites gebruikte formulieren, en welke effecten dat kan hebben op zijn klanten. Als iets niet echt nodig is, doe het dan niet.

Captcha's raad ik sowiese af voor kleine ondernemers. Gooi die paar spam-mailtjes per dag gewoon in je prullenbak en lig er niet wakker van.

Alternatieven voor captcha's

Er zijn goede alternatieven voor captcha's. Een webformulier (contactformulier, inschrijfformulier, aanmeldformulier et cetera) kan met diverse trucjes worden uitgerust die net als captcha's het aantal spam-berichten drastisch kunnen verminderen.

Alternatieven voor captcha's zijn bijvoorbeeld het door een gebruiker laten oplossen van een simpel rekensommetje, of het laten antwoorden op een vraag. Maar feitelijk hebben deze alternatieven het zelfde nadeel als een captcha: er wordt voor de websitebezoeker een barrière opgeworpen. Ze zijn eigenlijk een variant op een captcha, niet echt een alternatief.

Echt alternatief 1: verborgen velden in een formulier

Een echt alternatieve oplossing die ik als programmeur zelf graag gebruik is, en nu wordt het wat technischer, een verborgen veld toevoegen aan een webformulier. Dat veld ziet er uit als een gewoon invoerveld dat door een gebruiker zou moeten worden ingevuld. Een website bezoeker ziet dat veld echter niet omdat het door de website software (css: display:none;) verborgen wordt. Een spambot ziet dat veld wél, en zal proberen het in te vullen. Wanneer het formulier dan wordt verstuurd controleert de software of het verborgen veld is ingevuld. Is het ingevuld, dan is het dus duidelijk dat er een spambot aan het werk is geweest en kan het verwerken van het formulier dus worden afgebroken (en wordt er dus geen spam-mail verstuurd bijvoorbeeld). Een simpele maar effectieve oplossing waar de klant zelf helemaal niets van merkt.

Echt alternatief 2: meet de tijd waarin het formulier is ingevuld

Een andere goed werkende manier is met behulp van een tijdmeting. Het werkt heel simpel: bereken de tijd die de websitebezoeker nodig heeft gehad om het formulier in te vullen. Als die tijd zodanig kort is dat een mens dit nooit voor elkaar zou hebben gekregen, dan is de kans vrijwel 100% dat een spambot het formulier heeft ingestuurd. Immers, een spambot is een stukje software dat razendsnel is.
(let op: doe de tijdmeting server-side en niet met javascript, want een bezoeker kan javascript uitgeschakeld hebben staan).

Captcha's? Alleen als het écht niet anders kan.

Zo zijn er nog wel meer mogelijkheden om spammails te verminderen. Gebruik deze mogelijkheden eerst, voordat je besluit tot klantonvriendelijke captcha's en de varianten daarop. Gebruik captcha's alleen als het écht niet anders kan.


woensdag 15 augustus 2012

SQL-injecties grote bedreiging voor vrijwel alle websites

Wat is SQL?

SQL betekent letterlijk Structured Query Language. SQL is niet de database zélf, maar het is simpel gezegd de programmeertaal waarmee de gegevens in de database kunnen worden gelezen of gewijzigd. Iedere website die gebruik maakt van een database (en dat zijn vrijwel alle websites tegenwoordig, van CMS systemen als Joomla en Wordpress tot webshops en social media sites) heeft in zijn programmatuur SQL-opdrachten verwerkt om de gegevens in de database te kunnen lezen en schrijven.

Wat is een SQL-injectie?

Een SQL-injectie (spreek uit: 'sie-kwul'-injectie) is een methode die door hackers wordt gebruikt om de beveiliging van een database te omzeilen en op die manier toegang te krijgen tot de gegevens in die database. Wanneer er toegang is tot de gegevens in de database kan de hacker in principe alle gegevens in die database bekijken, wijzigen, vernietigen of kopiëren. Meestal heeft een hacker weinig goede bedoelingen wanneer hij toegang heeft gekregen tot een database..

Een SQL-injectie is een inbraak in uw website.

Wanneer een hacker een SQL-injectie uitvoert stuurt hij SQL-opdrachten naar de database die niet de bedoeling van de programmeur waren. De programmeur wilde bijvoorbeeld dat de database alleen bepaalde gegevens kon opslaan (denk aan emailadressen en wachtwoorden van gebruikers), maar niet dat die gegevens door website-bezoekers konden worden opgevraagd. Een hacker kan er met een SQL-injectie in slagen om die gegevens toch op te vragen, er er vervolgens alles mee te doen wat hij wil.
Een SQL-injectie is dus niets minder dan een inbraak in uw website met mogelijk grote gevolgen, en moet zo goed mogelijk voorkomen worden.

Verklein het risico op een SQL-injectie.

SQL-injecties kunnen worden voorkomen. Een goede programmeur weet wat hij moet doen om veilige 'scripts' (blokken programmeeropdrachten) te schrijven waarmee SQL-injecties onmogelijk zijn.
Zo zal een goede programmeur onder andere op de volgende zaken letten:
  • Alle ontvangen formuliergegevens van een website worden automatisch gecontroleerd op de aanwezigheid van SQL-injectiescripts;
  • Waar mogelijk maakt men gebruik van white-lists voor ingevoerde gegevens in plaats van black-lists;
  • Men stelt permissies in voor de database toegang zodanig dat de website alleen díe opdrachten mag uitvoeren die voor het functioneren van de site benodigd zijn en blokkeer het uitvoeren van alle overige (supervisor-) opdrachten;
  • Men gebruikt zogenaamde prepared statements;
  • et cetera..

Beveiliging is complex maar noodzakelijk.

Het gevaar van SQL-injecties is groot, maar kan met onder andere bovenstaande methodes vrijwel geheel worden voorkomen. Dat wil dan niet meteen zeggen dat de website en de database dan goed beveiligd zijn. Immers, wanneer wachtwoorden en login-gegevens niet veilig zijn, dan is er überhaupt geen SQL-injectie nodig om toegang tot de gegevens te krijgen.

Website beveiliging is een complex geheel, en verdient alle aandacht. Laat u bij twijfel goed informeren door uw website-bouwer of een onafhankelijk adviseur. De kosten wegen vrijwel altijd ruimschoots op tegen de baten. De bedrijfs- en imagoschades die het gevolg zijn van gehackte websites kunnen enorm zijn..



Uitgebreidere informatie specifiek voor programmeurs lees je onder andere op http://www.unixwiz.net/techtips/sql-injection.html.

dinsdag 3 juli 2012

Een website is nooit af. Blijf optimaliseren.

Als webdeveloper & -optimaliseerder zie ik veel websites. Ik bekijk ze vanuit het perspectief van een bezoeker om mezelf een beeld te vormen over de usability, maar zeker ook vanuit het oogpunt van een ontwikkelaar. Ik leer er van, want ik zie hoe anderen bepaalde dingen opgelost hebben.

Nu testte ik onlangs de website van de Wehkamp omdat ik zelf  bezig was met het ontwikkelen van een webshop. Prima Sony laptop in de aanbieding, direct leverbaar, van 1999,- nu voor 1488 euro. Dit artikel gekozen, geplaatst in mijn winkelmand, en alles leek in orde.



Goeie deal, en op voorraad..
 
Goeie deal, dus ik neem er gelijk maar 5. Eens even kijken wat er dan gebeurt, dacht ik. Ik had al een vermoeden namelijk. En ja, mijn vermoeden bleek juist: het artikel was uitverkocht, aldus de website, en of ik zo vriendelijk zou willen zijn het artikel te verwijderen of een andere maat te kiezen (..).



Waarom krijg ik er geen 4 aangeboden?

Blijkbaar was 1 exemplaar wél beschikbaar, maar de voorraad strekte niet tot de door mij gevraagde 5 stuks. Vandaar de 'uitverkocht'-melding. En blijkbaar denkt Wehkamp dat als ik er geen 5 kan krijgen, dat ik er dan liever helemaal geen wil. Jammer natuurlijk, want niet alle klanten zullen er zo over denken. Jammer dus, maar ook een gemiste kans op omzet, want waarom meldt de site niet dat er wél 4 stuks* te krijgen zijn? Daarmee de kans verhogend dat er toch een transactie plaats zal vinden.
Een paar regeltjes ontbrekende programmeercode kosten Wehkamp zo ongetwijfeld aardig wat euro's per jaar.

Quick-wins voor het oprapen

Je ziet, zelfs bij de grootste websites valt nog te verbeteren en liggen er regelmatig zelfs quick-wins voor het oprapen. Een website is nooit helemaal af. Altijd blijven zoeken dus is het devies, en misschien je site eens door laten lichten. Kan zomaar eens wat opleveren..!

(* Even puzzelen leidde tot de conclusie dat er op dat moment nog 4 stuks voorradig en leverbaar waren. Echter, het werd mij niet verteld; ik moest het zelf uitvogelen, en veel bezoekers zullen die moeite niet nemen).