Voorkom dat je event-website onderuit gaat

Na maanden je event voor te bereiden is eindelijk het moment aangebroken waarop de communicatie en de ticketverkoop van start gaat. En net dan begeeft je website het. Zelfs bij de meest professionele evenementen gebeurt het. Hoe je ervoor zorgt dat je website de druk wel aankan vraagt Kevin aan Bernard Grymonpon.

Kevin Van der Straeten
Reageer op deze tv aflevering

Heb je al een account op eventplanner.be? Meld je aan
Heb je nog geen account? Schrijf je comment hieronder:

Ook beschikbaar als podcast:

Ook via podcast:

Listen on Google PodcastsListen on Apple PodcastsListen on Shopify

Transcript

Na maanden je event voor te bereiden is eindelijk het moment aangebroken waarop de communicatie en de ticketverkoop van start gaat. En net dan begeeft je website het. Zelfs bij de meest professionele evenementen gebeurt het. Hoe je ervoor zorgt dat je website de druk wel aankan vraag ik aan Bernard Grymonpon.


Dag Bernard, welkom in de studio.

 

Dag Kevin.


Ik zei het in de intro al: heel veel mensen, organisatoren, hebben een evenementensite en op het moment dat die ticketverkoop van start gaat dan ligt die site plat. Hoe pak je dat nu aan om dat te verkomen?

 

Goh, er zijn een paar stappen in. Eerst en vooral goeie afspraken, je kiest goed leveranciers. Met uw leverancier, uw hostingpartner, ga je dan eigenlijk goeie afspraken maken. Zodat beide partijen kunnen weten wat ze kunnen verwachten. Hebben we het over honderd bezoekers? Duizend, tienduizenden bezoekers? Elk oplossing heeft een ander probleem. Ehh, elk probleem heeft een andere oplossing liever. Als dat er eenmaal is, dan moet de site gebouwd worden. Ook daar: luister naar uw hoster, vraag hem om input. Ga samenwerken naar een performante site.

 

Ja, want vaak is die koppeling er al niet, hè? De developer maakt de site, en dan de hoster; dat zijn voor heel veel mensen gescheiden...

 

Het gebeurt zeer veel dat dat zelfs ver weg staat, dat dat in het buitenland staat; Amerika of zoiets. Dat er zeer weinig contact is, dat het enkel wat help... is. Het kan echt wel lonen om eigenlijk een dicht contact te hebben met uw hoster; het is toch één van uw primaire leveranciers. Zij zorgen ervoor dat uw site online blijft, dus het is wel iemand waarmee je moet spreken... Maar je zegt wel: op voorhand goed inschatten hoeveel bezoekers.

 

Dat is ook niet altijd even makkelijk, hè?

 

Dat is niet altijd evident, maar een goede hoster zal dat al vooraf gedaan hebben. Die kan zeg maar gaan spiegelen aan andere cases, die kan eigenlijk een beetje gaan putten uit de kennis die hij al heeft opgedaan. Als je wat input kan geven over wat je doelpubliek is, welke vorm van reclame je gaat gebruiken, dan kunnen we daar toch al een hint krijgen.

 

Maar jij zegt: welke vormen van reclame. Dat betekent ook als je zegt van: "ik heb een TV-spot lopen", ik geef dan op voorhand door: dan en dan loopt die TV-spot want ik verwacht pieken in traffic.

 

Bijvoorbeeld, maar bijvoorbeeld ook zeer extreme pieken. Als je zegt: om 7 uur 's avonds moet iedereen naar de site gaan om een bepaalde code of korting of iets te krijgen... Ja of bij de lancering van bijvoorbeeld...

 

Laten we eens Tomorrowland als voorbeeld nemen.

 

Omdat u start de ticketsales, ja, dan is iedereen er tegelijk. Dan is iedereen er tegelijk. Dat is iets anders dan zeggen, bijvoorbeeld: deze week is er een kortingscode te vinden. Dan gaat dat bezoekersaantal al zeer gespreid zijn. Die heel hoge pieken, die zijn de hele moeilijke om op te vangen. Want die zijn zeer specifiek en moeten eigenlijk tussen de hoster en de programmeur zeer nauwzettend afgesproken worden, getest worden, en dan eigenlijk live gezet worden. En tijdens het live gaan moet er ook zeer goeie opvolging zijn. Dan moet de hoster weten waarmee dat hij bezig is, dan moet ook de programmeur eigenlijk bijna aanwezig zijn zodat als er iets fout gaat er snel en accuraat ingegrepen kan worden.

 

Nu, als ik op de website van hosters kijk dan zie ik daar heel wat pakketjes staan en voor 10 dollar per maand ben ik gesteld. Is dat dan een verstandige beslissing?

 

Nee, dat zou ik niet zeggen. Als je een gewone site hebt, informatief, waar gewoon wat volk naartoe komt, kun je daar zeker mee gediend zijn. Als je een zeer kleine shop hebt met enkele shoppers per dag: prima te doen. Maar als je eigenlijk een evenement gaat doen en je wil echt van de site een deel van uw communicatie maken; ga dan toch ten minste te rade bij uw hoster, laat iets maken op maat, zorg dat het aangepast is aan de mediacampagnes die je maakt, aan de publiciteit dat je eraan geeft, en zorg dat uw hoster ook op de hoogte is en u gaat ondersteunen daarin. Dat hij niet zegt: "het is uw probleem; mijn servers draaien", nee, de site zelf moet ook werken, de mensen die...

 

Ja, want daarover gaat het, hè: Is de site bereikbaar of niet?

 

Ja inderdaad, en dat is natuurlijk de hoofdzaak. Want zeer veel hosters gaan zeggen: "mijn server werkt en ik zie geen problemen op de server. Dat uw pagina blanco is of dat hij er maar half doorkomt, dat is mijn probleem niet. Dat is de programmacode".

Daar hebben wij toch een iets andere insteek, en daar gaan we eigenlijk ook mee helpen om te kijken dat de site echt wel degelijk werkt en dat het resultaat er is. Want dat is wat telt op het einde van de rit.

 

Maar voor een evenement, kan ik me voorstellen, dat is toch een moeilijke situatie. Want de helft van het jaar heb je vaak geen bezoekers op je website, of heel weinig. En dan op bepaalde momenten; de dag van het evenement, de start van de campagne, de start van de ticketverkoop, heb je gigantische...

 

Daar zijn de zaken aan te passen, hè? We kunnen dat door het jaar heen eigenlijk op een vrij klein pakket laten lopen,

dat het weinig noden heeft. En ook minder kost. En dat het minder kost inderdaad. En op het moment dat we natuurlijk gaan naar het evenement, iets ervoor gaan we zien dat de bezoekersaantallen beginnen te stijgen afhankelijk van het evenement. En dan gaan we eigenlijk ook de site verhuizen naar krachtigere hardware.

 

Is dat dan 'de cloud' zoals ze dat zeggen?

 

Ja neen, de cloud is een beetje een allesomvattend begrip. Het komt er wel op neer dat zoals de cloud verkocht wordt dat het meegroeit met wat je nodig hebt. Onderliggend is het iets ingewikkelder: we gaan het gewoon verhuizen naar andere servers en naar meerdere servers, maar het voelt wel aan alsof het altijd dezelfde hosting is maar dan net met gewoon meer capaciteit.

 

Je steekt er gewoon PK bij?

 

Je steekt er PK bij; het ene moment zit je in een Lada en zonder dat je het merkt een dag daarna zit je in een Porsche en...

Op het moment dat je het nodig hebt. Het ziet er allemaal hetzelfde uit en op het moment dat je het nodig hebt is die er.

 

Wat je dan ook heel veel leest is caching, CDN's, wat zijn dat dan?

 

Caching is bijvoorbeeld een techniek die zeer veel gebruikt wordt, want dat is dé sleutel eigenlijk om zeer performante sites te gaan hebben. Een site opbouwen en de programmacode daarna moet bepaalde zaken gaan verzamelen. Die gaat dat allemaal samenstellen en die gaat die pagina terugsturen naar de bezoeker. De eerste bezoeker: wordt allemaal gedaan, de tweede bezoeker: krijgt eigenlijk dezelfde pagina. Waarom zou je nog eens al dat werk gaan doen als je gewoon al de berekeningen hebt gedaan? Caching gaat ervoor zorgen dat die eerste berekening opgeslagen wordt, de tweede bezoeker krijgt gewoon...

Krijgt identiek dezelfde pagina. Identiek dezelfde pagina zonder berekenen, het is gewoon hop, klaar.

 

Dus dat is een ideale oplossing voor statische informatie zoals de informatie over je evenement en zo verder maar dat gaat natuurlijk niet helpen in een ticketshop.


In een ticketshop gaat dat u niet helpen, in een E-shop bijvoorbeeld wel. In een webwinkel zijn de productdetails voor iedereen hetzelfde. Het is pas als je eens naar de kassa gaat en je begint af te rekenen, daar zit je dan natuurlijk met iets anders. Ticketsites zijn natuurlijk iets anders. Daar moeten we eigenlijk gaan werken met heel andere systemen. Een stuk van de inschrijving kan gecached worden. Het moment dat de data dan eigenlijk door de klant ingegeven wordt en naar de server teruggestuurd wordt, dan moet er daar code zijn die zo performant is dat die zeer snel die data opneemt en in de database zet, zonder al te veel berekeningen, en gewoon doorgaat naar de volgende bezoeker. En daarvoor moet je weer samenwerken met de programmeurs en de makers van de website.

 

Die dan de nodige aanpassingen daarvoor maken?

 

Die de nodige aanpassingen moeten doen en normaal gezien zou de hoster hen zeker in het begin van het traject de nodige tips moeten geven om daar verder goed mee te kunnen werken. 

 

En dan misschien het laatste: CDN, wat is dat?

 

CDN is... ja, een beest. Servers staan op één bepaalde plaats in de wereld. Stel je dat je een wereldwijd evenement hebt of toch wereldwijde inschrijvingen, dan kun je eigenlijk ervoor zorgen dat er meerdere servers zijn die uw data hebben, en dan gaan bezoekers vanuit de US bijvoorbeeld servers in de Verenigde Staten gaan gebruiken terwijl bezoekers in Europa servers in Europa gebruiken.

 

Dat eigenlijk alles wat dichterbij brengt.

 

Ja inderdaad. Het brengt nieuwe moeilijkheden met zich mee, want iemand die inschrijft in Europa moet natuurlijk ook een ticket gaan blokkeren in Amerika en vice versa maar daar zijn ook oplossingen voor.

 

We hebben in ieder geval heel veel bijgeleerd, ik onthoud vooral: praat met je hoster.

 

Zeker, punt één.


Oké Bernard, super bedankt voor je komst naar de studio.

 

Oké, graag gedaan.


En u, beste kijker; bedankt voor het kijken en alweer tot volgende week.

Advertenties