Lösningar · SaaS
Driv ert eget program, på er egen webbplats
Ert team äger färdplanen och kör testerna. Pertento är plattformen under, en skripttagg, en visuell redigerare och resultat ingen behöver ta på tro.
Att driva det själva
Från den första eftermiddagen och framåt
Att installera det, vem ni bjuder in, och hur en ändring skeppas när det inte finns någon utvecklingstid att lägga på det.
Komma i gång
Live samma eftermiddag
En skripttagg i head och konsolen börjar rapportera. Inget att upphandla, ingen datapipeline att bygga, ingen utvecklingssprint att schemalägga.
- En spårare på 0,9 KB, inga kakor, ingen personlig data
- Den visuella redigeraren körs från ett Chrome-tillägg på er livesida
- Ett nytt experiment är ett utkast till dess ni startar det och publicerar webbplatsen
Teamet
Bjud in alla, betala för sessioner
Prissättningen är per session på webbplatsen, inte per plats, så designern som skriver varianten och analytikern som läser resultatet kostar inget extra.
- Obegränsat antal användare på alla planer
- Roller för vem som kan starta, stoppa och driftsätta
- En aktivitetslogg över vem som ändrade vad
Utan utveckling
Skeppa ändringen, lämna över vinnaren
De flesta varianter behöver aldrig en utvecklare. De som är värda att behålla ger upphov till ett implementeringsärende med selektorn och den exakta ändringen, så överlämningen är en klistring snarare än ett möte.
- No-code-redigering av text, formgivning, layout och position
- Implementeringsöverlämning för vinnare värda att hårdkoda
- Experimentet fortsätter levereras till dess koden skeppas
I praktiken
Så ser det ut att driva det själva en tisdag
Det svåra med ett internt program är sällan det första testet. Det är att hålla flera av dem i rörelse när experimentering inte är någons hela jobb.
Er takt begränsas inte av trafiken
Varje behörig besökare går in i varje behörigt experiment, så ett litet team kan ha åtta tester live på en medelstor webbplats utan att något av dem tar längre tid att avgöra. Rådet att köra ett i taget är en begränsning i andra verktyg.
Backloggen avgör, inte den som talar högst
Poängsätt varje idé på potential, exponering och arbetsinsats, och listan ordnar sig själv. När inget är trasigt och inget väntar på beslut säger konsolen vilket utkast ni ska ta upp.
Läsbehörighet är en verklig roll
Medlemmar ser allt och ändrar inget, vilket är det som gör det tryggt att ge hela teamet ett konto. Att starta, stoppa och driftsätta ligger hos administratörer och ägare, och varje ändring registreras på experimentet med ett namn på.
Det andra testet är billigare än det första
När ni duplicerar ett experiment följer varianterna, ändringarna, skärmbilderna och alla tre typer av styrning med. Det mesta av kostnaden i ett program är att bygga upp uppsättningar igen, och de flesta felen sitter i den del som byggs om för hand.
Ingen behöver komma ihåg att stoppa det
Schemalägg start och slut när ni bygger testet. Stopp vid signifikans finns som tillägg, med en minsta körtid och ett obligatoriskt slutdatum, så att ett tidigt stopp bara kan vara tidigt och aldrig det enda som avslutar ett test.
Den säger till när ett test går sönder
En fördelning som slutat stämma med sin konfiguration, eller en dag helt utan trafik, når er via e-post och Slack i stället för att vänta på att upptäckas. Båda betyder oftast att en driftsättning tog bort skriptet eller att en styrregel slutade matcha.
Frågor
Innan ni tar det in i huset
Hur litet får teamet vara?
En person som kan redigera webbplatsen och läsa ett diagram. Det arbete som normalt kräver en specialist är just det som är inbyggt: redigeraren tar bort utvecklaren ur de flesta varianter, ordningen i backloggen tar bort diskussionen om vad som ska köras härnäst, och kön över vad som behöver ett beslut tar bort den dagliga kontrollen av om något gått sönder. Vad den inte kan är att avgöra vad som är värt att testa, och det kan ingen plattform. Om ingen äger den frågan skapar inte inköp av programvara en ägare.
Vad kommer våra utvecklare att behöva göra?
Tre saker, och bara den första är oundviklig. Lägga ett skript i head, en gång, vilket är den enda ändringen på er webbplats. Bygga serversidesexperiment, där er egen backend avgör vad som visas, vilket är den enda experimenttypen som verkligen är kod. Och hårdkoda vinnare när ni vill att en ändring ska ligga i er egen kodbas i stället för att levereras av oss, vilket lämnas över med den exakta ändringen bifogad och är en inklistring snarare än ett möte. Allt däremellan görs genom att peka på element på er livesida.
Hur beter sig kostnaden när vi växer?
Den följer testad trafik och inte antalet anställda, så de personer som gör ett program möjligt bär inte var sitt pris. Designern som skriver varianten, analytikern som läser resultatet och intressenten som vill titta på kan alla ha konto, och medlemmar har läsbehörighet i hela plattformen, så det är tryggt att dela ut de kontona. Det som växer med er är trafiken ni skickar genom tester, vilket är den del som hänger samman med vad ni får tillbaka.
Vi har redan GA4. Ersätter det här det?
Nej, och det är bättre om ni behåller det. Ställ in webbplatsen på GA4 och körtiden läser de händelser som redan flödar genom ert datalager, så att de konverteringar vi mäter är samma som er analys räknar. Det tar bort den vanliga tvisten mellan två verktyg med två definitioner av ett köp. Variantexponeringen skickas också tillbaka ut, så ett test blir en dimension ni kan segmentera på i den rapportering ert team redan litar på.
Vad händer med arbetet om vi slutar?
Allt som redan är hårdkodat ligger i er egen kodbas och påverkas inte, vilket är precis därför implementeringskön envisas med vinnare som vi fortfarande levererar. Vinnare som fortfarande levereras av plattformen slutar när den slutar, på samma sätt som vilken variant som helst slutar. Experimenten, hypoteserna bakom dem och registret över varje beslut ligger i kontot i stället för i ett kalkylblad hos en konsult, så det ni går ifrån med är ett dokumenterat program snarare än en mapp med skärmbilder.