Een slechte app-update kan een golf van terugbetalingen veroorzaken, en zo houd je die tegen voordat hij je uitbetaling raakt

Wanneer een release kapot wordt uitgebracht, beginnen de terugbetalingen voordat je crashdashboard dat doet. Een slechte app-update irriteert mensen niet alleen. Hij geeft ze een concrete reden om hun geld terug te vragen, en bij een goedkope aankoop is het geld het kleinste deel van wat je verliest. De rekenkracht die je al hebt verbruikt, de externe API-aanroepen die je in rekening zijn gebracht en de opslag die je hebt ingericht, komen niet terug met de verkoop.

Het nuttige is dat een kapotte release een van de weinige oorzaken van terugbetalingen is die je in minuten kunt afremmen, niet in weken. Beide stores brengen een update in fasen uit en laten je hem halverwege stopzetten, en die ene besturing is het verschil tussen een handvol getroffen gebruikers en een golf van terugbetalingen tegen je uitbetaling. Dit kost een golf van terugbetalingen werkelijk, zo houd je een slechte release in elke store tegen, en dit zijn de twee korte vensters die je enige stem zijn zodra er al een geschil is ingediend.

Waarom een slechte app-update verandert in terugbetalingen

Een crash bij het opstarten, een paywall die niet laadt, een functie die gisteren werkte en vandaag niet. Elk daarvan geeft een betalende klant een zuivere reden om zijn geld terug te vragen, en een terugbetaling is de beleefde versie van die reactie. De onbeleefde versie is een chargeback bij de bank. Beide kosten je geld, en een release die zelfs voor een deel van je gebruikers stukgaat, kan er genoeg opleveren om op je uitbetaling te verschijnen.

Het geld dat je verliest is meer dan de verkoop

Wanneer een aankoop wordt terugbetaald, gaat het verkoopbedrag terug naar de klant. Wat niet terugkomt, is alles wat je al hebt uitgegeven om die aankoop te bedienen. De rekenkracht die het werk uitvoerde, de externe API-aanroepen die je op het moment van gebruik in rekening zijn gebracht, de opslag die je hebt ingericht, en elke uitbetaling die je al aan een maker hebt gestuurd, zijn weg. Bij een goedkoop verbruiksartikel kunnen die verzonken kosten plus een mogelijke bankkost samen meer bedragen dan de klant ooit heeft betaald.

Een golf van terugbetalingen verhoogt ook je terugbetalingspercentage

Terugbetalingen zijn niet alleen een verlies per verkoop. Kaartnetwerken en beide stores houden bij in welk tempo je verkopen terugkomen. Eén kapotte release die dat percentage doet pieken, kan controle aantrekken die je liever vermijdt, dus de kost van een slechte update omvat de reputatie die je uitgeeft, niet alleen het geld.

Hoe je een slechte release stopt in de App Store

Apple's middel om schade te beperken is de gefaseerde release, en de hele waarde ervan is dat je aan de rem kunt trekken voordat de meeste van je gebruikers de kapotte build ooit zien.

Gefaseerde release loopt over zeven dagen

Wanneer je gefaseerde release inschakelt voor een versie-update, levert Apple die aan een willekeurige steekproef van gebruikers met automatische updates aan. De uitrol klimt volgens een vast schema: 1 procent op dag één, daarna 2, 5, 10, 20, 50 en 100 procent over zeven dagen. Omdat de eerste dagen een klein deel van je basis raken, heeft een fout die op dag twee wordt opgevangen veel minder mensen bereikt dan een volledige release op dezelfde dag zou hebben gedaan.

Pauzeer op het moment dat er iets mis lijkt

Als een slechte app-update erdoor glipt, kun je de gefaseerde release op elk moment pauzeren. Apple laat je tot 30 dagen pauzeren, zonder limiet op hoe vaak je pauzeert, en het budget is cumulatief: pauzeer 10 dagen, hervat, en je hebt nog 20 dagen pauze over. Wanneer je hervat, pakt de uitrol op bij de dag waarop hij stopte. Pauzeren haalt de build niet weg bij gebruikers die hem al hebben, dus koppel de pauze aan een fix en een versnelde beoordeling.

Hoe je een slechte release stopt in Google Play

Google Play geeft je twee remmen, een voor een release die nog wordt uitgerold en een voor een release die iedereen al heeft bereikt.

Zet een lopende gefaseerde uitrol stop

Met een gefaseerde uitrol in Google Play kun je uitbrengen aan een percentage gebruikers en dat op je eigen schema verhogen. Als je een probleem vindt, open je de release en kies je Uitrol beheren, daarna Uitrol stopzetten. Geen extra gebruikers ontvangen de versie, en de gebruikers die hem al hebben, blijven erop. Als de build toch schoon blijkt, hervat je dezelfde uitrol vanaf het punt waar hij stopte.

Zet een release stop die al naar 100 procent is gegaan

Google Play laat je ook een volledig uitgerolde release stopzetten, iets wat de rem van de gefaseerde uitrol niet kan. Wanneer je hem stopzet, neemt een eerder live, volledig uitgerolde versie van je app automatisch de plaats in voor nieuwe en bestaande gebruikers die de stopgezette build nog niet hebben. Twee beperkingen tellen: je kunt de eerste release op een track niet stopzetten, en als de kapotte versie lang genoeg live is dat de meeste gebruikers al hebben bijgewerkt, helpt stopzetten weinig, want de schade is al verspreid.

Wanneer de terugbetalingen en geschillen al in gang zijn

Een uitrol faseren beperkt hoeveel mensen op een slechte app-update stuiten. Het doet niets voor de terugbetalingen en geschillen van de gebruikers die dat al deden. Zodra een klant zijn geld terugvraagt, doorloopt de store de procedure, en jouw stem is smal.

De meeste terugbetalingen worden zonder jou beslist

De terugbetaling met zelfbediening binnen 48 uur van Google Play, terugbetalingen via support en geannuleerde aankopen worden allemaal door de store beslist onder zijn eigen beleid. Er is geen bewijskanaal en geen beroep. Daarvoor is jouw dossier de terugbetaling zelf en de kost die je al hebt geslikt. De enige plek waar je kunt handelen, is preventie, en precies daarom is de uitrolrem van belang.

Twee vensters zijn je enige inbreng

Slechts twee procedures vragen iets van je. Wanneer een klant een terugbetaling vraagt voor een verbruiksartikel of een automatisch verlengend abonnement, stuurt Apple je server een CONSUMPTION_REQUEST en wacht tot 12 uur op verbruiksgegevens. Op Google Play start een betwiste aankoop die beoordeling nodig heeft een klok van 24 uur, en je antwoordt via de orders.reviewrefund-API. Mis een van beide vensters en de beslissing wordt zonder jou genomen. Geen van beide vensters laat je een slechte release ongedaan maken. Ze laten je alleen reageren op de nasleep ervan.

De checklist voor schadebeperking

Niets hiervan is exotisch. Het is een korte routine die je bij elke release uitvoert, niet alleen bij de releases waarvan je verwacht dat ze stukgaan.

• Breng elke update uit via gefaseerde release in de App Store en gefaseerde uitrol in Google Play, nooit een volledige uitrol op dezelfde dag.
• Houd crash- en terugbetalingssignalen in de gaten tijdens de eerste dagen met een laag percentage, wanneer het publiek klein genoeg is om te beschermen.
• Pauzeer de gefaseerde release in de App Store of zet de uitrol in Google Play stop op het moment dat er een echte fout opduikt, en herstel en dien opnieuw in.
• Voor een fout die iedereen op Google Play al heeft bereikt, zet je de volledig uitgerolde release stop zodat de vorige versie de plaats inneemt.
• Richt de meldingsfeeds van Apple en Google in zodat je elk verbruiksverzoek en elke terugbetalingsbeoordeling binnen het venster kunt beantwoorden.
• Volg je terugbetalingspercentage gedurende de hele release, want een piek is het signaal dat een terugrol al te laat is.