Hoe scoor je als marketeer echt met een second screen?

Tekst: Joerek van Gaalen*

Het second screen biedt mooie kansen voor meer interactie met je publiek en de kijker ook buiten de uitzending aan je te binden.

Maar wat als je applicatie op dat tweede scherm het op het moment suprême laat afweten zoals het geval was bij de Nationale IQ-test? Heb je een flink gedeelte van je marketingbudget in de app-ontwikkeling gestoken, blijkt hij onder piekbelasting te bezwijken. Het second screen biedt veel marketingmogelijkheden, maar kan je ook lelijk in de voet bijten als de app of mobiele website niet soepel loopt.

Hoe bereid je je goed voor op de toestroom gebruikers en scoor je echt met een second screen?

Een ding gemeen

Second screen-applicaties hebben één ding gemeen: ze hebben binnen een hele korte tijd enorm veel gebruikers en activiteit. Een hele andere situatie dan bij (mobiele) websites of applicaties waarvan het gebruik veel evenwichtiger is verdeeld. Hier komen bezoekers niet allemaal binnen een kwartier binnen en klikken ze niet allemaal binnen 10 seconden op de betaal,- of stemknop.

Daarom zou het testen van piekbelasting een vast onderdeel moeten zijn tijdens het bedenken en ontwerpen van een applicatie.

Een massale toestroom van gebruikers veel vraagt van de servers waarop de applicatie draait. Het is vrij complex om een omgeving zodanig in te richten dat het deze enorme bulk aan belasting goed kan verwerken. Maar het is mogelijk, met een goede voorbereiding en aandacht voor onderstaande punten:

1. Brief je ontwikkelaar met performance als doel

Het kunnen verwerken van bulkverzoeken kan bijna alleen maar goed gaan als de applicatie zeer effectief is ontwikkeld.

De tijd dat de applicatie reageert op een verzoek van een gebruiker (bijvoorbeeld het invullen van een vraag of openen van een link), moet zo kort mogelijk zijn. Enerzijds om de gebruikers snel van dienst te zijn, anderzijds om de verwerkingscapaciteit zo klein mogelijk te houden.

Hoe sneller een gebruiker bedient wordt, hoe minder gelijktijdige openstaande verzoeken verwerkt hoeven te worden. Kortom, een systeem dat snel verzoeken verwerkt, kan ook meer verzoeken aan. Zorg er bij de briefing van je ontwikkelaars ervoor dat het doel en vereisten van de app duidelijk zijn.

Ontwikkelaars dienen zich namelijk bij het schrijven van elke regel code bewust te zijn wat de impact zou kunnen zijn als die regel bij wijze van spreken 100.000x per seconde wordt uitgevoerd. Performance moet een doel zijn.

2. Zorg dat je app makkelijk kan opschalen

Het is belangrijk dat de applicatie schaalbaar wordt ontwikkeld, waarbij de belasting niet wordt beperkt door een enkele database. Als je bijvoorbeeld een app ontwikkelt voor een TV-show waarbij constant nieuwe antwoorden worden toegestuurd, is het belangrijk te kiezen voor een zogeheten decentrale database.

De applicatie moet zo zijn ingericht dat je heel eenvoudig nieuwe servers kunt bijschakelen, zonder dat je deze daarna nog handmatig moet configureren. Zo wordt het heel makkelijk om bijvoorbeeld cloud-diensten te gebruiken waarbij je precies zoveel virtuele systemen start als je nodig hebt.

Het voordeel daarvan is dat er heel eenvoudig, met een druk op de knop, virtuele systemen opgestart kunnen worden die binnen een minuut bruikbaar zijn. Hier zal ook je IT-collega blij mee zijn.

3. Plan tijd in voor testen

Zodra de app live is wil je natuurlijk zo snel mogelijk live. Stel je geduld alleen nog heel even op de proef en plan wat tijd in om je app goed te testen. Websites of apps die in hele korte tijd een enorme hoeveelheid gebruikers of verzoeken verwerken, hebben per definitie een enorm groot performance-risico. Je ziet nog te vaak dat een app die de doelgroep aan het merk moest binden, ze juist afstoot door slechte performance.

Mijn ervaring is dat de kans dat zo’n (nieuwe) applicatie direct een goede performance levert, nihil is.

Om voor de inzet van deze applicaties de performance inzichtelijk te maken, is het uitvoeren van performance-testen een must. Performance testen moeten antwoorden geven op de volgende kritieke vragen:

• Wat is de maximale capaciteit van de omgeving en kan het de verwachte belasting wel aan?

• Schalen de servers mee; snel genoeg en zonder fouten?

• Is mijn applicatie wel optimaal ontwikkeld en zijn de servers optimaal ingericht voor dergelijke belasting?

In de laatste jaren heb ik veel grote performance-testen uitgevoerd waarbij testen van 100.000 tot een miljoen gelijktijdige gebruikers geen uitzondering waren. En nooit was de performance in één keer zoals gewenst.

Als je maximaal wil profiteren van de inzet van het second screen en wil presteren op het moment dat het ertoe doet, denk dan aan een goede generale repetitie. Loop het hele proces door alsof het al een live-uitzending betreft. Vraag het maximale van de applicatie. Pas dan kun je echt scoren met je second screen-app en de gebruiker aan je binden.

* Joerek van Gaalen is cto performance bij Computest