Løsninger · SaaS
Kjør deres eget program, på deres eget nettsted
Teamet deres eier veikartet og kjører testene. Pertento er plattformen under, én skripttagg, en visuell editor og resultater ingen trenger å ta på tro.
Å kjøre det selv
Fra den første ettermiddagen og videre
Å installere det, hvem dere inviterer, og hvordan en endring sendes når det ikke finnes utviklingstid å bruke på det.
Komme i gang
Live samme ettermiddag
Én skripttagg i head og konsollen begynner å rapportere. Ingenting å anskaffe, ingen datapipeline å bygge, ingen utviklingssprint å planlegge.
- En sporer på 0,9 KB, ingen informasjonskapsler, ingen personopplysninger
- Den visuelle editoren kjøres fra en Chrome-utvidelse på nettstedet deres
- Et nytt eksperiment er et utkast til dere starter det og publiserer nettstedet
Teamet
Inviter alle, betal for økter
Prisen er per økt på nettstedet, ikke per plass, så designeren som skriver varianten og analytikeren som leser resultatet, koster ikke ekstra.
- Ubegrenset antall brukere på alle planer
- Roller for hvem som kan starte, stoppe og rulle ut
- En aktivitetslogg over hvem som endret hva
Uten utvikling
Send endringen, overlever vinneren
De fleste varianter trenger aldri en utvikler. De som er verdt å beholde, gir en implementeringssak med selektoren og den eksakte endringen, slik at overleveringen er en innliming heller enn et møte.
- No-code-redigering av tekst, styling, layout og posisjon
- Implementeringsoverlevering for vinnere verdt å hardkode
- Eksperimentet fortsetter å levere til koden er sendt
I praksis
Slik ser det ut å kjøre det selv en tirsdag
Det vanskelige med et internt program er sjelden den første testen. Det er å holde flere av dem i bevegelse når eksperimentering ikke er noens hele jobb.
Takten deres begrenses ikke av trafikken
Hver kvalifisert besøkende går inn i hvert kvalifisert eksperiment, så et lite team kan ha åtte tester live på et middels stort nettsted uten at noen av dem tar lengre tid å avgjøre. Rådet om å kjøre én om gangen er en begrensning i andre verktøy.
Backloggen avgjør, ikke den som roper høyest
Gi hver idé poeng på potensial, eksponering og innsats, og listen ordner seg selv. Når ingenting er ødelagt og ingenting venter på en beslutning, sier konsollen hvilket utkast dere skal ta opp.
Lesetilgang er en reell rolle
Medlemmer ser alt og endrer ingenting, og det er nettopp det som gjør det trygt å gi hele teamet en konto. Å starte, stoppe og rulle ut ligger hos administratorer og eiere, og hver endring registreres på eksperimentet med et navn på.
Den andre testen er billigere enn den første
Når dere dupliserer et eksperiment følger variantene, endringene, skjermbildene og alle tre typer styring med. Det meste av kostnaden i et program er å bygge opp oppsett på nytt, og de fleste feilene sitter i den delen folk bygger om for hånd.
Ingen må huske å stoppe den
Planlegg start og slutt når dere bygger testen. Stopp ved signifikans kommer i tillegg, med en minste kjøretid og en obligatorisk sluttdato, slik at en tidlig stopp bare kan være tidlig og aldri det eneste som avslutter en test.
Den sier fra når en test går i stykker
En fordeling som har sluttet å stemme med oppsettet, eller en dag helt uten trafikk, når dere på e-post og Slack i stedet for å vente på å bli oppdaget. Begge betyr oftest at en utrulling tok skriptet, eller at en styringsregel sluttet å treffe.
Spørsmål
Før dere tar det inn i huset
Hvor lite kan teamet være?
Én person som kan redigere nettstedet og lese et diagram. Arbeidet som normalt krever en spesialist er nettopp det som er innebygd: editoren fjerner utvikleren fra de fleste variantene, rekkefølgen i backloggen fjerner diskusjonen om hva som skal kjøres neste gang, og køen over hva som trenger en beslutning fjerner den daglige sjekken av om noe er ødelagt. Hva den ikke kan, er å avgjøre hva som er verdt å teste, og det kan ingen plattform. Hvis ingen eier det spørsmålet, skaper ikke innkjøp av programvare en eier.
Hva må utviklerne våre gjøre?
Tre ting, og bare den første er uunngåelig. Legge ett skript i head, én gang, som er den eneste endringen på nettstedet deres. Bygge eksperimenter på serversiden, der deres egen backend avgjør hva som vises, som er den ene eksperimenttypen som virkelig er kode. Og hardkode vinnere når dere vil at en endring skal ligge i deres egen kodebase i stedet for å leveres av oss, som overleveres med den eksakte endringen vedlagt og er en innliming heller enn et møte. Alt mellom dette gjøres ved å peke på elementer på det live nettstedet.
Hvordan oppfører kostnaden seg når vi vokser?
Den følger testet trafikk og ikke antall ansatte, så folkene som gjør et program mulig bærer ikke hver sin pris. Designeren som skriver varianten, analytikeren som leser resultatet og interessenten som vil følge med kan alle ha konto, og medlemmer har lesetilgang i hele plattformen, så det er trygt å dele ut de kontoene. Det som vokser med dere er trafikken dere sender gjennom tester, som er den delen som henger sammen med hva dere får tilbake.
Vi har allerede GA4. Erstatter dette det?
Nei, og det er bedre om dere beholder det. Sett nettstedet til GA4, og kjøretiden leser hendelsene som allerede flyter gjennom datalaget deres, slik at konverteringene vi måler er de samme som analysen deres teller. Det fjerner den vanlige uenigheten mellom to verktøy med to definisjoner av et kjøp. Varianteksponeringen sendes også tilbake ut, så en test blir en dimensjon dere kan segmentere på inne i den rapporteringen teamet deres allerede stoler på.
Hva skjer med arbeidet hvis vi slutter?
Alt som allerede er hardkodet ligger i deres egen kodebase og berøres ikke, som er nøyaktig derfor implementeringskøen fortsetter å mase om vinnere vi ennå leverer. Vinnere som fortsatt leveres av plattformen stopper når den stopper, på samme måte som enhver variant stopper. Eksperimentene, hypotesene bak dem og loggen over hver beslutning ligger i kontoen heller enn i et regneark hos en konsulent, så det dere går fra med er et dokumentert program heller enn en mappe med skjermbilder.