Nustokite ginčytis dėl krepšelio palikimo: gaukite atsiskaitymo pataisymų patvirtinimą

Santrauka

Dauguma patarimų apie krepšelio palikimą daro prielaidą, kad kliūtis yra jūsų atsiskaitymas—formos, mygtukai, žingsnių skaičius. Jei dirbate mažoje vidaus rinkodaros komandoje, tikroji kliūtis dažniausiai yra vidinė: netechninis vadovas, kuris nori įrodymų, kūrėjų darbų sąrašas, ankstesnis nesėkmingas eksperimentas arba miglotas jausmas, kad „tai ne rinkodaros darbas“. Šis straipsnis šiuos prieštaravimus traktuoja kaip savarankiškas konversijų optimizavimo problemas. Jis parodo, kaip „parodyk man duomenis“ paversti vienos popietės auditu, kaip atskirti kodo pakeitimus nuo teksto ir nustatymų pakeitimų, ir kodėl supaprastinimas be pasitikėjimo nepajudins rodiklių. Taip pat gausite lentelę su penkiais dažniausiai išgirstais prieštaravimais ir tiesų atsakymą apie kompromisą dėl svečių atsiskaitymo. Tikslas—padaryti jūsų kitą prašymą tokį konkretų ir mažą, kad jis nustotų būti diskusija ir taptų planu.

Dauguma patarimų apie krepšelio palikimą parašyti žmonėms, kurie jau gali keisti savo atsiskaitymą. Jie sako supaprastinti formą, pridėti svečių atsiskaitymą, parodyti pristatymo išlaidas prieš paskutinį žingsnį, tarsi vienintelis dalykas, skiriantis jus nuo geresnio konversijų rodiklio, yra žinojimas, ką daryti. Jei esate mažoje vidaus rinkodaros komandoje, tai retai būna problema. Jūs jau žinote, kokie yra pataisymai. Problema ta, kad kiekvienas pataisymas turi išgyventi pokalbį su netechniniu vadovu, kuris nori įrodymų, grafiko ir sąnaudų įvertinimo, kol jums bus leista ką nors keisti.

Kas iš tikrųjų veikia, yra ne ilgesnis taktikų sąrašas. Tai požiūris, kad pats patvirtinimo procesas yra konversijų optimizavimo problemos dalis. Pasipriešinimas, kurį girdite—„neturime duomenų“, „negame gauti kūrėjo laiko“, „jau bandėme tai anksčiau“, „tai ne mūsų darbas“—nėra triukšmas. Kiekvienas prieštaravimas jums sako, kurią projekto dalį dar nepadarėte konkrečia. Atsakykite į prieštaravimą, ir pakeitimas nustoja būti prašymu ir tampa planu.

Šis straipsnis apžvelgia penkis prieštaravimus, kurie sustabdo daugumą atsiskaitymo pataisymų, su nuolatiniu pavyzdžiu, ir baigiasi lentele, kurią galite atsinešti į kitą biudžeto susitikimą. Pagrindinė mintis paprasta: geriausias konversijų optimizavimo žingsnis, kurį galite padaryti šį ketvirtį, nėra perprojektavimas. Tai padaryti kitą pakeitimą pakankamai mažą, kad jūsų vadovas galėtų pasakyti „taip“ nejausdamas, kad lošia.

„Parodyk man duomenis“ reiškia parodyk man piltuvą

Tarkime, dirbate mažoje lauko įrangos įmonėje. Jūsų vadovas ką tik pasakė, kad pristatymo išlaidos žudo užsakymus. Ji atsilošia ir sako: „Tai stiprus teiginys. Ar turime duomenų?“ Neturite įrankio, kuris parodytų, kur pirkėjai iškrenta. Pradedate kalbėti apie sesijų įrašus ir įvykių stebėjimą, o jos akys pradeda blėsti. Projektas miršta susitikime.

Klaida čia yra manyti, kad „duomenys“ turi reikšti prietaisų skydelį, kurio neturite. Daugeliui ankstyvų pataisymų jums reikalingi duomenys jau egzistuoja jūsų parduotuvėje—tik dar neperėjote jos kaip pirkėjas. Elektroninės prekybos vadovai nuosekliai nurodo nedidelį priežasčių, dėl kurių žmonės palieka krepšelį, rinkinį: netikėtos išlaidos, sudėtingas atsiskaitymo procesas, prievarta susikurti paskyrą, pasitikėjimo trūkumas, riboti mokėjimo būdai ir lėtas pristatymas. Tas sąrašas yra jūsų audito kontrolinis sąrašas.

Štai ką su juo daryti. Atidarykite inkognito langą ir eikite į savo produkto puslapį. Įdėkite kuprinę į krepšelį. Dabar slinkite lėtai, darydami ekrano kopiją kiekviename žingsnyje. Kada pirkėjas pirmą kartą mato bendrą kainą, įskaitant pristatymą? Suskaičiuokite ekranus tarp „įdėti į krepšelį“ ir „jums bus nurašyta ši suma“. Pabandykite atsiskaityti be paskyros susikūrimo ir pažymėkite tikslų momentą, kai esate užblokuotas. Raskite savo grąžinimo politiką ir pažymėkite, kiek paspaudimų reikia ją perskaityti. Pakartokite viską telefone, kur išdėstymas visada elgiasi kitaip.

Gausite penkiolika ar dvidešimt ekrano kopijų ir pastebėjimų rinkinį, kuris atrodo taip: „Krepšelio puslapyje nėra paminėta pristatymo kaina. Mokėjimo puslapyje pristatymo mokestis pasirodo pirmą kartą. Atsiskaitymas prašo paskyros prieš mokėjimą. Grąžinimo politikos nuoroda yra poraštėje, šešios pastraipos žemiau.“ Tai įrodymai, ir su jais sunku ginčytis, nes jūsų vadovas gali juos atkartoti per dvi minutes.

Viena detalė, kuri padaro auditą aštresnį: atlikite jį su kolega, kuris niekada nematė jūsų svetainės. Nustebsite, ką nepastebite, kai esate įpratę prie sistemos. Paprašykite jų garsiai kalbėti, kol jie bando ką nors nusipirkti. Jūs nevykdote naudojamumo laboratorijos; klausotės momentų, kai normalus žmogus sako „palauk, ką?“ Tie yra būtent tie momentai, kuriuose gyvena krepšelio palikimo priežastys.

Kai pristatote auditą, nepradėkite nuo pataisymo. Pradėkite nuo atkūrimo: „Įdėkite šią prekę, eikite į krepšelį ir ieškokite pristatymo. Dabar pabandykite atsiskaityti be paskyros.“ Leiskite vadovui pačiam patirti nusivylimą. Žmogus, kurį suerzino jūsų atsiskaitymas, nebėra skeptikas; jis yra sąjungininkas.

Bendras principas: prieš prašydami pakeitimo, duokite savo vadovui ką nors, ką jis gali pamatyti ir patikrinti, o ne teiginį, kuriuo reikia tikėti. Ekrano kopija verta daugiau nei prognozė. Toks auditas taip pat padeda išvengti dažniausios mažų komandų konversijų optimizavimo klaidos—siūlyti pataisymą problemai, kurios iš tikrųjų nepatvirtinote. Jei svarstote, ar jūsų problema yra pats atsiskaitymas, ar kažkas anksčiau piltuve, ankstesnis straipsnis apie tikrosios palikimo priežasties diagnostiką yra naudingas kitas žingsnis.

„Neturime kūrėjo laiko“ dažniausiai reiškia, kad neatskyrėte nustatymų nuo kodo

Jūsų vadovas išgirsta „atsiskaitymo optimizavimas“ ir įsivaizduoja kūrėją, dirbantį dvi savaites. Žinote, kad darbų sąrašas yra trijų mėnesių, todėl net nesiteikiate paklausti. Tačiau daugumai standartinio palikimo sąrašo pataisymų kūrėjas apskritai nereikalingas.

Paimkite keturis didžiuosius. Skaidrios kainos: pristatymo išlaidų rodymas arba pranešimas „nemokamas pristatymas nuo tam tikros sumos“ dažnai yra sakinys, kurį galite pridėti prie krepšelio puslapio arba nustatymas jūsų platformoje. Svečių atsiskaitymas: daugelyje elektroninės prekybos platformų tai yra perjungiklis nustatymuose, o ne individualus kūrinys. Mokėjimo būdai: iš tikrųjų pridėti naują mokėjimo teikėją yra techninis darbas, tačiau rodyti, kuriuos būdus priimate, yra ženklelis arba piktograma atsiskaityme—rinkodaros teritorija. Grąžinimo politika: aiški, sąžininga grąžinimo politika yra tekstas, o nuorodą į ją gali perkelti bet kas, kas gali redaguoti puslapį.

Grįžkime prie jūsų lauko įrangos įmonės sekundei. Grąžinimo politika palaidota poraštėje, o pirkėjai, kurie nerimauja dėl pirkimo, jos niekada neranda. Jūsų vadovas mano, kad pataisymas reiškia „perkurti poraštę ir šabloną“. Tačiau tikrasis pataisymas yra pridėti vieną teksto eilutę po mygtuku „Įdėti į krepšelį“: „Grąžinimas per 30 dienų, be klausimų—žr. mūsų politiką.“ Nuoroda veda į puslapį, kuris jau egzistuoja. Tai turinio valdymo sistemos pakeitimas, o ne sprintas.

Nustatymų punktas taip pat svarbus. Jei jūsų platforma turi svečių atsiskaitymo parinktį, jos įjungimas nėra kodo pakeitimas; tai konfigūracijos pakeitimas. Gali tekti rasti nustatymą, perskaityti dokumentaciją ir išbandyti vieną kartą—bet tai popietės darbas, o ne kūrėjo sprintas. Jei neturite prieigos prie nustatymų puslapio, kartą paprašykite prieigos. Pirmą kartą kūrėjas gali turėti jus pervesti; antrą kartą galėsite padaryti patys.

Dar viena kategorija: užsakymo patvirtinimo puslapis ir el. laiškas. Jei patvirtinimas yra bendrinis arba nenustato pristatymo lūkesčių, tai dar vienas rinkodarai priklausantis paviršius. Galite jį perrašyti neliesdami užsakymų sistemos. Klientai, kurie žino, kas bus toliau, rečiau rašo palaikymui, o palaikymo el. laiškų apimtis yra metrika, kurią jūsų vadovas supras.

Įspėjimas vertas aiškaus pasakymo: kai kurie pataisymai tikrai reikalauja kodo, ir apsimetimas priešingai kainuos jūsų patikimumą. Tačiau prieštaravimas dažnai iškyla todėl, kad prašymas buvo suformuluotas kaip „sutvarkykite atsiskaitymą“, o ne „pakeiskite šį sakinį krepšelio puslapyje“. Suformuluokite pakankamai mažą, kad jis priklausytų rinkodarai, ir pusė pasipriešinimo išnyks. Kai jums tikrai reikės kūrėjo, turėsite daug stipresnį argumentą, jei galėsite pasakyti „viskas šiame sąraše yra tekstas ir nustatymai—tik šis vienas punktas reikalauja kodo“.

„Jau bandėme supaprastinti“ reiškia, kad taisėte netinkamą priežastį

Prieš šešis mėnesius kažkas jūsų komandoje pašalino tris laukus iš atsiskaitymo formos. Vadovas į tai nurodė kaip į įrodymą, kad „jau bandėme konversijų optimizavimą“. Užsakymai nepasikeitė. Dabar siūlote su pasitikėjimu susijusį pataisymą, ir vadovas klausia: „Kodėl tai būtų kitaip?“

Priežastis, kodėl būtų kitaip, yra ta, kad formos supaprastinimas ir pasitikėjimo kūrimas sprendžia skirtingas problemas. Tyrimai ir kasdienė patirtis rodo, kad žmonės palieka krepšelius, kai nepasitiki parduotuve—kai grąžinimo politika neaiški, mokėjimo būdai atrodo menki arba domenas atrodo nepažįstamas. Jei tai yra pagrindinė priežastis, trumpesnė forma nepadeda. Įsivaizduokite, kad perkate brangią kuprinę iš parduotuvės, apie kurią niekada negirdėjote. Atsiskaitymas yra trys laukai, kuo švariausi. Vis tiek dvejojate, nes rizika yra ne forma—o tai, ar daiktas atvyks, ir ar galėsite jį grąžinti, jei ne. Ta dvejonė nėra naudojamumo problema; tai įtikinėjimo problema.

Kaip sužinoti, ar pasitikėjimas yra priežastis? Pažiūrėkite į detales. Ar jūsų produktai yra brangūs, palyginti su tuo, ką impulsyvus pirkėjas rizikuotų? Ar jūsų parduotuvė nauja arba domenas atrodo neįprastai? Ar prie pirkimo mygtuko nėra grąžinimo politikos? Ar nėra atsiliepimų arba jų labai mažai? Jei į kelis iš jų atsakėte „taip“, pasitikėjimas tikriausiai yra didesnis veiksnys nei formos ilgis. Jei jūsų forma tikrai ilga—dešimt ar daugiau laukų, su neprivalomais, kurie netinka—tada sudėtingumas gali būti problema. Esmė ta, kad turite patikrinti, o ne spėti.

Praktiškas būdas patikrinti, ar pagrindinė priežastis yra pasitikėjimas ar sudėtingumas: pridėkite tik vieną pasitikėjimo elementą—grąžinimo politikos nuorodą prie mygtuko „Įdėti į krepšelį“—ir palikite formą nepaliestą. Jei palaikymo klausimai dėl grąžinimo arba elgesio paliekant puslapį pagerėja, tikriausiai problema buvo pasitikėjimas. Jei niekas nesikeičia, tada pažiūrėkite į sudėtingumą.

Yra ir naudingas priešingas punktas. Pasitikėjimo signalų pridėjimas nėra automatinis laimėjimas. Jei įdėsite atsiliepimų valdiklį į savo produkto puslapį ir neturite jokių atsiliepimų, ką tik parodėte klientams „0 atsiliepimų“—o tai yra blogiau nei visai nerodyti. Paprasta, konkreti garantijos eilutė, pagrįsta tikra grąžinimo politika, yra sąžiningesnė ir nieko nekainuoja. Panašiai, „supaprastinti“ formą nėra tas pats, kas slėpti būtinus laukus. Jei jums reikia pristatymo adreso, jis reikalingas; pašalinus jį, kad forma būtų trumpesnė, sukelsite neteisingus pristatymus ir grąžinimus. Supaprastinimas turėtų pašalinti nereikalingą naštą, o ne perkelti ją kitur.

Tas niuansas yra ta pati logika, kaip ir tai, kodėl „supaprastink viską“ požiūris į atsiskaitymą yra klaidingas. Ne tai, kad supaprastinimas yra blogas; tai, kad supaprastinimas yra vienas iš kelių svertų, ir traukdami jį nežinodami, kurią priežastį sprendžiate, galite iššvaistyti ketvirtį.

„Pirmiausia mums reikia plano“ iš tikrųjų yra proceso prašymas

Jūsų vadovas sako: „Gerai, įtikinote mane, kad yra problema. Dabar parašykite man planą.“ Jūs sustingstate, nes įsivaizduojate metų trukmės eksperimentų programą su statistiniu reikšmingumu ir planu. Žinote, kad neturite tam srauto ar biudžeto, todėl stringate.

Planui nereikia būti ambicingam. Tai gali būti viena kilpa: pasirinkite vieną priežastį iš palikimo kontrolinio sąrašo, raskite ekraną, kuriame ji nepavyksta, padarykite vieną pakeitimą ir stebėkite vieną metriką. Tada pereikite prie kitos priežasties.

Padarykime tai konkrečiai su lauko įrangos įmone. Jūsų auditas parodė, kad pristatymas nustebina žmones mokėjimo puslapyje. Jūsų šio mėnesio planas: pridėti eilutę prie krepšelio puslapio, kad pristatymo kaina apskaičiuojama atsiskaitymo metu ir kad visada ją parodysite prieš mokėjimą. Metrika, kurią stebite, yra palaikymo el. laiškų, klausiančių apie pristatymą, skaičius ir paprasta prieš-paskui analizė, kiek žmonių, pasiekiančių mokėjimo puslapį, iš tikrųjų užbaigia užsakymą. Tai viskas. Jei palaikymo el. laiškai sumažėja ir atsiskaitymo užbaigimas nesumažėja, pagerinote patirtį. Kitą mėnesį iškelsite grąžinimo politikos nuorodą. Po mėnesio, jei jūsų platforma leidžia, įjungsite svečių atsiskaitymą. Tai planas.

Konkrečiai planas galėtų atrodyti taip. Pirmą savaitę: atliekate auditą ir parodote vadovui ekrano kopijas. Antrą savaitę: redaguojate krepšelio puslapį, kad paminėtumėte pristatymą, ir paprašote klientų aptarnavimo pradėti žymėti pristatymo klausimus. Trečią savaitę: patikrinate platformos nustatymą dėl svečių atsiskaitymo ir jį įjungiate arba parengiate paskyros raginimo tekstą. Ketvirtą savaitę: peržiūrite palaikymo pastabas ir pažiūrite į atsiskaitymo užbaigimo skaičių. Tai planas, kurį jūsų vadovas gali įdėti į kalendorių, o tai būtent ir reiškia žodis „planas“ netechniniam vadovui.

Įspėjimas čia yra apie per daug dalykų keitimą vienu metu. Mažoje svetainėje turite žinoti, kuris pakeitimas davė rezultatą. Vienas pakeitimas per savaitę ar mėnesį yra lėtas, kuo pasigirti, bet greitas, ko išmokti. A/B testai yra prabanga; dėl akivaizdžios nesėkmės prieš-paskui metrikos, kuri jums rūpi, peržiūra dažnai pakanka kitam žingsniui pagrįsti. Jei norite formalesnės šios kilpos versijos, mūsų vadovas, kaip sukurti pakartojamą konversijų optimizavimo procesą elektroninės prekybos klientams, išdėsto veiksmus.

Dar vienas dalykas: pasirinkite proceso metriką, o ne bendras pajamas. Pajamos svyruoja dėl šimto priežasčių. Proceso metrika—pavyzdžiui, „kaip dažnai palaikymas mini pristatymą“, „kiek toli vidutinis pirkėjas nueina prieš išeidamas“ arba „kiek atsiskaitymo puslapio peržiūrų virsta užsakymais“—pasako, ar konkretus pakeitimas atliko savo darbą. Jei neturite tam analitikos, naudokite žmogiškąjį grįžtamąjį ryšį: paprašykite klientų aptarnavimo pradėti pažymėti, kai klientas paminėjo pristatymo netikėtumą. Tai taip pat duomenys.

„Tai ne rinkodaros darbas“ išnyksta, kai valdote žinią

Susitikime kūrėjas sako, kad atsiskaitymas yra puikus. Produkto žmogus sako, kad tai darbo eigos problema. Jūsų vadovas sako, kad kažkas turėtų tuo užsiimti, ir visi žiūri į grindis. Jūs nerimaujate, kad rinkodara neturi įgaliojimų atsiskaitymui, todėl tyli.

Štai performulavimas: atsiskaitymas yra vieta, kur jūsų rinkodaros pažadas susiduria su išbandymu. Jei jūsų produkto puslapis sako „nemokamas pristatymas nuo tam tikros sumos“, o atsiskaitymas be paaiškinimo ima mokestį už pristatymą, tai žinios nesėkmė. Rinkodara valdo garantijų formuluotes, sąnaudų skaidrumą ir pasitikėjimo signalų vietą—o tai yra didžioji dalis palikimo kontrolinio sąrašo. Pikselių išdėstymas yra kūrėjo sritis; istorija, kurią klientas skaito stovėdamas prie atsiskaitymo slenksčio, yra jūsų.

Taigi jums nereikia įgaliojimų kodų bazei, kad ką nors pakeistumėte. Jums reikia sąrašo žinučių, kurios šiuo metu nepavyksta, ir būtent tai piltuvo auditas ir sukuria. Kai jį pristatote, neprašote leidimo keisti architektūrą; pranešate, kad rinkodaros žinutė nutrūksta konkrečiame taške. Naudinga frazė vadovui: „Aš neprašau valdyti atsiskaitymo. Aš prašau valdyti ant jo esančius žodžius.“ Šis skirtumas mažas, bet galingas—jis padaro prašymą mažiau teritorišku ir labiau panašiu į švaros klausimą.

Yra gilesnė šio prieštaravimo versija, kurią verta įvardyti. Jei jūsų įmonė konversijų optimizavimą laiko specialisto darbu, maža vidaus komanda dažnai jaučiasi nepakankamai kvalifikuota. Tačiau jums nereikia būti statistikui, kad pastebėtumėte žinios nesėkmę. Jums reikia būti žmogumi, kuris pastebi, kad krepšelio puslapis žada viena, o mokėjimo puslapis pateikia kita. Tai rinkodaros įgūdis, o ne duomenų mokslo laipsnis. Jei nerimaujate dėl proceso, pradėkite nuo straipsnio apie paslėptą nutekėjimą, kuris buvo parašytas būtent tokioms komandoms.

Nuorodų lentelė kitam biudžeto susitikimui

Iki šiol modelis turėtų būti aiškus: kiekvienas prieštaravimas yra skirtingas prašymas—parodyk įrodymus, parodyk, kad maža, parodyk, kad tai ne praeities kartojimas, parodyk planą, parodyk, kad tai mūsų. Štai jie vienas šalia kito su atsakymu, kuris paprastai suveikia.

Prieštaravimas	Ką iš tikrųjų reiškia	Ką pasakyti ar daryti
„Neturime duomenų“	„Man reikia pamatyti, kad patikėčiau.“	Atlikite vienos popietės auditą ir pasidalykite ekrano kopijomis tikslios nesėkmės vietos.
„Negalime gauti kūrėjo laiko“	„Aš bijau didelio projekto.“	Pirmiausia pasiūlykite teksto, nustatymų ir politikos pakeitimus; palikite kodą nuošalyje.
„Jau bandėme supaprastinti“	„Konversijų optimizavimas anksčiau neveikė.“	Parodykite, kad supaprastinimas ir pasitikėjimas sprendžia skirtingas priežastis, ir įvardykite, kurią priežastį nukreipiate.
„Pirmiausia mums reikia plano“	„Noriu proceso, o ne noro.“	Pasiūlykite vieno mėnesio kilpą: viena priežastis, vienas pakeitimas, viena metrika.
„Tai ne rinkodaros darbas“	„Man reikia savininko, kuriuo pasitikiu.“	Atneškite ekrano kopijas, kaip rinkodaros žinutės nepavyksta atsiskaitymo viduje.

„O kas, jei pablogės?“ nusipelno tiesaus atsakymo

Paskutinis prieštaravimas yra tas, kuris sustabdo žmones vietoje, nes jis protingas. Jūsų vadovas sako: „Jei įjungsime svečių atsiskaitymą, prarasime visus nuolatinius klientus.“ Jaučiatės įspraustas į kampą, nes tai tikėtinas rezultatas.

Sąžiningas atsakymas yra tas, kad svečių atsiskaitymas nėra viskas arba nieko. Kompromisas tikras, bet galite jį suprojektuoti: leiskite žmonėms atsiskaityti kaip svečiams, o tada paraginkite juos susikurti paskyrą po užsakymo su nauda, kurią jie tikrai vertina—užsakymo sekimas, greitesnis pakartotinis užsakymas, lojalumo taškai. Taip išlaikote didžiąją dalį konversijų naudos ir vis tiek suteikiate klientams priežastį registruotis.

Taip pat galite tai pateikti kaip bandomąjį projektą: „Paleiskime svečių atsiskaitymą dvi savaites ir stebėkime, kas atsitiks su paskyrų kūrimu. Jei paskyros sumažės, o pajamos nepasikeis, galime grįžti atgal.“ Grįžtamasis bandomasis projektas paverčia nuolatinį skambantį pakeitimą mažos rizikos testu.

Gilesnis dalykas yra tai, kad kiekvienas konversijų pataisymas yra mainai, o mainai priklauso nuo jūsų verslo modelio. Jei valdote prenumeratos paslaugą, kuri priklauso nuo paskyrų, bendras svečių atsiskaitymas gali tikrai jums pakenkti. Teisingas klausimas yra ne „ar svečių atsiskaitymas geras?“, o „ką mes norime iškeisti ir ką galime padaryti vietoj to?“ Tai niuansas, kurio praleidžia bendri geriausios praktikos sąrašai, ir todėl mažos komandos sprendimas svarbesnis už kontrolinį sąrašą.

Ta pati mainų logika taikoma mokėjimo būdams. Riboti mokėjimo būdai yra dažna palikimo priežastis—bet pridėti daugiau būdų nėra nemokama. Kiekvienas papildomas būdas prideda sąranką, mokesčius, sukčiavimo riziką ir palaikymo klausimus. Jei dauguma jūsų klientų jau moka vienu būdu, ilgas logotipų sąrašas gali atrodyti įspūdingai, nekeisdamas elgesio. Žingsnis yra patikrinti, ką jūsų klientai iš tikrųjų naudoja, o ne kopijuoti didžiausią parduotuvę, kurią galite rasti.

Tai taip pat taikoma greičiui. Lėtas pristatymas yra palikimo sąraše, bet paprastai negalite ištaisyti pristatymo greičio nustatymu. Ką galite padaryti, tai nustatyti tikslius lūkesčius: jei žinote, kad produktui gabenimas trunka savaitę, sakykite „gabenama per 5 darbo dienas“ vietoj to, kad slėptumėte. Klientas, kuris žino laukimą, yra klientas, kuris gali nuspręsti; klientas, kuris sužino po apmokėjimo, yra grąžinimas.

Išvada: padarykite kitą pakeitimą pakankamai mažą, kad į jį būtų galima atsakyti taip

Prieštaravimų valdymas nėra minkštasis įgūdis. Tai prioritetų nustatymas. Kai jūsų vadovas prašo duomenų, jis sako, kad projektas per abstraktus. Kai sako, kad nėra kūrėjo laiko, jis sako, kad projektas skamba per didelis. Kai sako, kad anksčiau neveikė, jis sako, kad priežastis niekada nebuvo patvirtinta. Įvardykite tikrąjį blokavimą, ir sprendimas tampa mažesnis, labiau matomas ir labiau grįžtamas.

Vieno puslapio auditas, vienas sakinys krepšelio puslapyje, svečių atsiskaitymas kaip nustatymas, grąžinimo politikos nuoroda, perkelta vienu paspaudimu arčiau sprendimo—nė vienas iš jų neprivers jūsų jaustis, kad darote „tikrą“ konversijų optimizavimą. Tačiau tai pakeitimai, kurie išgyvens pokalbį su netechniniu vadovu, nes jie mažai kainuoja, trunka dienas ir gali būti atšaukti, jei neveikia. Pradėkite nuo vieno nutekėjimo, apie kurį jau žinote, duokite savo vadovui ką nors, ką galima paspausti, ir leiskite rezultatui vesti kitą argumentą.

Paskutinis įspėjimas: nė vienas iš šių dalykų negarantuoja konversijų padidėjimo. Gali būti, kad atliksite pakeitimus ir nepamatysite skirtumo, nes tikrasis blokavimas yra kažkas, ko negalite pamatyti iš parduotuvės vidaus. Būtent dėl tos galimybės ir laikote pakeitimus mažus ir grįžtamus. Klaidos kaina maža; nieko nedarymo kaina, nes laukėte tobulo įrodymo, yra ketvirtis praleistų pardavimų.