Proaktīva Chatbot uzruna: trigeri, frequency caps un cieņpilna UX
Proaktīvi Chatbot norādījumi palīdz tikai tad, ja konteksts, laiks un biežums ir pareizi. Šajā rokasgrāmatā parādīti konkrēti trigeru noteikumi, ierobežojumi mobilajām ierīcēm, piekļūstams dizains un godīga panākumu mērīšana.
Proaktīva Chatbot uzruna īstajā brīdī var vērst apmeklētāju uzmanību uz noderīgu saīsni. Tomēr tā var tikpat ātri pārvērsties par digitālu pārdevēju, kas nepūlēts aizsprosto ceļu. Tāpēc izšķirošais nav tas, vai norāde parādās automātiski, bet gan tas, uz kādu atpazīstamu vajadzību tā reaģē, cik diskrēti tā ir izstrādāta un vai noraidījums tiešām tiek akceptēts.
Labi noteikumi apvieno trīs perspektīvas: cilvēka uzdevumu, pašreizējās lapas slodzi un biznesa ieguvumu. Šī rokasgrāmata pārvērš šīs perspektīvas praktiskā sistēmā, kas sastāv no trigeriem, izņēmuma noteikumiem, frequency caps, piekļūstamām mijiedarbībām un pārbaudāmiem kvalitātes rādītājiem.

Proaktīvs nenozīmē uzbāzīgs
Proaktīva norāde vispirms ir tikai aicinājums. Tā kļūst uzbāzīga, ja pārtrauc pašreizējo uzdevumu, aizsedz skatu, pārņem fokusu, parādās uzreiz pēc aizvēršanas vai rada mākslīgu problēmu. Tāpēc dizainam vajadzētu sekot vienkāršam noteikumam: vispirms uzticams palīdzības signāls, tad neliels aicinājums, un tikai pēc apzinātas aktivizēšanas — dialogs.
Tas atšķir palīdzības sniegšanu no autostarta tērzēšanas. Diskrēta norāde, piemēram, „Jautājumi par piegādes iespējām?“, atbilstošā vietā var būt noderīga. Savukārt nepūlēts atvērts logs ar skaņu, animāciju un obligātu lēmumu prasa uzmanību, pirms ir skaidra vajadzība. Tiem, kas vēl tikai plāno tehnisko integrāciju, papildus jāņem vērā norādes par Chatbot integrāciju, nepasliktinot UX vai SEO.
Trigeri no lietotāju signāliem, nevis no intuīcijas
Laika vērtība vien reti ir labs signāls. Desmit sekundes lapā var nozīmēt intensīvu orientēšanos, lēnu lasīšanu, tālruņa zvanu vai vienkārši neaktīvu cilni. Daudz izteiksmīgākas ir lapas konteksta un uzvedības kombinācijas. Šajā gadījumā daži saprotami noteikumi parasti sniedzas tālāk nekā grūti izskaidrojams vērtēšanas modelis.
Spēcīgi, uz uzdevumu orientēti signāli
- Atkārtota navigācija: Lietotājs vairākas reizes pārslēdzas starp cenu, pakalpojumu vai piegādes informāciju.
- Atpazīstams pārtraukšanas punkts: Tiek sākta daudzpakāpju forma, bet tā netiek turpināta laukā, kam nepieciešams paskaidrojums.
- Mērķtiecīga produkta pārbaude: Pēc kārtas tiek atvērti varianti, priekšnoteikumi vai tehniskās detaļas.
- Kļūdas ar palīdzības potenciālu: Ievade atkārtoti neizdodas, Chatbot neesot vajadzībai minēt datus vai lēmumus.
- Atgriešanās ar to pašu vajadzību: Definētā, pret datiem saudzīgā kontekstā atkal tiek apmeklēta tā pati informācijas lapa.
Vāji signāli tikai kā papildinājums
Ritināšanas dziļums, uzturēšanās ilgums un Exit-Intent var sniegt papildu norādes, taču tiem nevajadzētu lemt vieniem pašiem. Peles kursors augšējā malā uz skārienekrāniem neeksistē; ilgs uzturēšanās laiks bez redzamas cilnes maz ko izsaka. Page Visibility API ļauj atpazīt neaktīvas vai aizsegtas cilnes. Uz laiku balstītiem trigeriem vajadzētu darboties tikai tik ilgi, kamēr lapa ir redzama un persona tiešām ir aktīva.
Izņēmuma noteikumi ir tikpat svarīgi kā trigeri
Katram trigera noteikumam ir nepieciešams pretstats, kas novērš norādes parādīšanos. Aicinājumam nevajadzētu parādīties, ja tērzēšana jau ir atvērta, persona šobrīd raksta, iesniedz formu, notiek maksājuma vai autentifikācijas solis vai ir redzams cits svarīgs dialogs. Arī pēc skaidras aizvēršanas nomākšanai jābūt prioritātei.
Saprātīga prioritāte ir šāda: drošības un transakciju stāvoklis pirms lietotāja lēmuma, lietotāja lēmums pirms kampaņas loģikas, konkrēta palīdzība pirms vispārīgiem ziņojumiem. Tas novērš situāciju, kad mārketinga norāde pārklāj atbalsta vai darījuma pabeigšanas uzdevumu.
Frequency Caps: atgādinājuma modelis nepārtraukta spiediena vietā
Frequency Caps ierobežo ne tikai rādīšanas reizes. Tie saglabā faktu, ka cilvēks jau ir pieņēmis lēmumu. Pirmajam testam var pietikt ar vienkāršu modeli:
- Vienā sesijā parādās visvairāk viens proaktīvs aicinājums.
- Pēc aktīvas aizvēršanas spēkā ir vairāku dienu miera periods, piemēram, septiņas dienas kā pārbaudāma sākuma vērtība.
- Pēc veiksmīgas izmantošanas tā pati norāde pārējam uzdevuma ceļam tiek nomākta.
- Vairāki tiesīgi noteikumi nekonkurē; fiksēta prioritāte izvēlas visvairāk vienu aicinājumu.
- Atkārtota aizvēršana pagarina miera periodu, nevis palielina spiedienu.
Šie skaitļi nav universāli kritēriji. Reti izmantotam B2B portālam ir nepieciešamas citas robežas nekā bieži apmeklētai servisa lapai. Svarīgi ir tas, ka sākuma vērtības tiek dokumentētas, izvērtētas pēc ierīces un lapas tipa un pielāgotas, balstoties uz noraidīšanas signāliem.
Mobilajās ierīcēs valda stingrāki telpas un laika ierobežojumi
Maza izmēra ekrānos pat kompakts runas burbulis var aizsegt saturu, navigāciju vai ekrāna tastatūru. Tāpēc aicinājumam nevajadzētu pārklāt primāro pogu, jāsaglabā pietiekams attālums no sīkfailu un sistēmas norādēm un jāpazūd, kad ir atvērta tastatūra. Īpaši ritināšanas laikā ir vēlama miermīlība: norādi drīkst parādīt tikai pēc īsa, stabila posma.
Pielāgojams noteikumu kopums ņem vērā arī pieejamo augstumu, nevis tikai platumu. Ļoti mazos skata logos neuzkrītoša nozīmīte (badge) var būt piemērotāka nekā teksta burbulis. Pilna saruna atveras tikai pēc apzinātas darbības.
Aizvēršanai un fokusam jādarbojas uzticami
Aizvēršanai jābūt pieejamai kā skaidri apzīmētai darbībai, ko var sasniegt ar tastatūru; Escape taustiņam vajadzētu aizvērt atvērtu sarunu, ja tādējādi netiek zaudēta ievadītā informācija. Tikai dekoratīvs „X“ bez pieejama nosaukuma nav pietiekams. Vēl svarīgāk: proaktīva norāde nedrīkst nepūlēti pārvietot tastatūras fokusu.
WCAG 2.2 standartā „On Focus“ ietvaros prasīts, ka komponentes fokusēšana pati par sevi neizraisa konteksta maiņu. Statusa informācijai saskaņā ar WCAG 4.1.3 par statusa ziņojumiem jābūt atpazīstamai palīgtehnoloģijām, nepārņemot fokusu. Dialogam, kas atvērts pēc lietotāja darbības, WAI-ARIA dialoga paraugs nodrošina uzticamu orientāciju fokusa vadībai, Escape uzvedībai un fokusa atgriešanai.
Ja aicinājums pārvietojas vai atjauninās automātiski, ir svarīgas arī prasības par pauzi, apturēšanu un paslēpšanu. Praksē mierīgs, statisks aicinājums parasti ir vienkāršāks un patīkamāks nekā pulsējošas vai atkārtotas animācijas. Sīkāku pārbaudi piedāvā WCAG kontrolsaraksts mākslīgā intelekta tērzēšanas botiem.
Ziņojumam godīgi jāatspoguļo atpazītais konteksts
Labs aicinājums nosauc konkrētu, faktiski pieejamu palīdzību. „Vai man paskaidrot šo variantu atšķirības?“ ir labāk pārbaudāms nekā „Es precīzi zinu, kas jums nepieciešams“. Formulējums nedrīkst ne tēlot piekļuvi personīgajiem datiem, ne radīt mākslīgu steidzamību. Tāpat atpakaļskaitīšanai, mākslīgam trūkumam un kauninošām noraidīšanas opcijām nav vietas cieņpilnā uzrunā.
Daudzvalodu tīmekļa vietnēm ziņojums tiek ne tikai iztulkots, bet katrā lokalizācijā tiek pārbaudīts tā garums, tonis un saikne ar darbību. Trigeris var darboties vienādi visās valodās, lai gan teksta garums un lasīšanas virziens var mainīt attēlojumu. Ja zināšanu bāze konkrētam jautājumam nav pietiekama, aicinājumam nevajadzētu solīt risinājumu, bet nepieciešamības gadījumā piedāvāt drošu nodošanu cilvēkam. Tam atbilst rokasgrāmata par Human Handoff tīmekļa vietņu atbalstā.
Veiktspēja ir daļa no prompt kvalitātes
Norāde nav noderīga, ja tās loģika samazina lapas ātrumu pie pirma klikšķa. Trigeru novērtēšanai, animācijai un logrīka ielādei nevajadzētu nevajadzīgi bloķēt galveno pavedienu (main thread). Google dokumentētais rādītājs Interaction to Next Paint (INP) novērtē lietotāja mijiedarbību reakcijas ātrumu visā lapas apmeklējuma laikā. Tāpēc promptam nevajadzētu sākt garus sinhronus uzdevumus, un apjomīgas tērzēšanas funkcijas vēlams ielādēt tikai reālas izmantošanas gadījumā.
Tehniskajai pieņemšanai pieder pārbaude uz lēnām mobilajām ierīcēm, ar samazinātu kustību, navigāciju ar tastatūru un nestabilos tīklos. Kļūda tērzēšanas skriptā nedrīkst bloķēt ne saturu, ne navigāciju. Lapas galvenajam uzdevumam vienmēr jāpaliek lietojamam.
Mērīt panākumus, neiekrītot uz atvēršanas līmeņa slazdu
Augsts atvēršanas līmenis var nozīmēt, ka aicinājums bija būtisks. Taču tas var rasties arī no pārāk lielas platības vai pārprastas aizvēršanas. Tāpēc mēriet visu ceļu:
- pamatotie trigeri un faktiskie attēlojumi, sadalīti pēc noteikuma un ierīces;
- apzinātas atvēršanas, tieša aizvēršana un atkārtota aizvēršana;
- sniegtās palīdzības mērķi, piemēram, atbildēts jautājums par produktu, pabeigts solis vai izvēlēts Handoff;
- pārtraukšana, atgriešanās navigācijā un formas kļūdas pēc attēlošanas;
- veiktspējas vērtības, kā arī logrīka tehniskās kļūdas.
Ievāciet tikai datus, kas ir nepieciešami šī lēmuma pieņemšanai, un definējiet uzglabāšanu, kā arī piekļuvi pirms eksperimenta. Raksts par pret datiem saudzīgu Chatbot analītiku parāda tam piemērotu notikumu un pārskata struktūru.
Kontrolētam eksperimentam ir nepieciešami aizsardzības rādītāji
Salīdziniet ne tikai konversiju, bet arī aizsardzības rādītājus, piemēram, Dismiss-Rate, atkārtotu noraidīšanu, lapas pamešanu, fokusa kļūdas un INP. Pirms starta nosakiet, pie kāda negatīva signāla variants tiek pauzēts. Neliela papildu pieteikumu (lead) vērtība neattaisno ievērojami sliktāku lietojamību.
Vispirms testējiet skaidri norobežotu lapu un vienu trigera noteikumu. Pēc tam mainiet tikai vienu dimensiju, piemēram, laiku, tekstu vai Frequency Cap. Pretējā gadījumā paliek neskaidrs, kura izmaiņa izraisīja efektu. Kvalitatīvas izlases no anonimizētām sarunu vēsturēm var izskaidrot, kāpēc kvantitatīvais signāls pieaug vai krītas.
Saprotama noteikumu kopuma piemērs
B2B produkta sadaļā aicinājumu varētu atļaut tikai tad, ja ir atvērtas vismaz divas tehniskās detaļu sadaļas, lapa ir redzama, kopš pēdējās mijiedarbības ir pagājis īss miera periods un nav aktīva ne forma, ne tērzēšana. Ja norāde šajā sesijā jau ir rādīta vai pēdējo septiņu dienu laikā aizvērta, tā netiek rādīta. Mobilajās ierīcēs vispirms parādās tikai kompakta palīdzības poga ar tekstu.
Ziņojums attiecas uz uzdevumu: „Jautājumi par priekšnoteikumiem vai variantiem?“. Pēc atvēršanas Chatbot piedāvā divus skaidrus sākuma punktus un aizvēršanas darbību. Ja tas nevar sniegt saistošu paziņojumu no apstiprinātiem avotiem, tas norāda robežu un sagatavo nodošanu. Šī loģika ir pietiekami vienkārša, lai to izskaidrotu komandā un pilnībā nosegtu testos.
Kontrolsaraksts pirms palaišanas (Go-live)
- Vai trigeris ir sasaistīts ar konkrētu uzdevumu, nevis tikai ar laiku?
- Vai ir dokumentēti izņēmuma noteikumi formām, transakcijām un aktīviem dialogiem?
- Vai aizvēršana tiek ievērota vairākās sesijās?
- Vai tastatūras fokuss paliek nemainīgs līdz apzinātai aktivizēšanai?
- Vai ir pārbaudīta aizvēršana, Escape, ekrāna lasītāja paziņojumi un samazināta kustība?
- Vai aicinājums mazos skata logos neaizsedz svarīgus vadības elementus?
- Vai veiktspēja, pārtraukšana un noraidīšana ir definēti kā aizsardzības rādītāji?
- Vai ir skaidrs, kad Chatbot nodod sarunu cilvēkam vai klusē?
- Vai visas atbalstītās valodas ir pārbaudītas ar reālu teksta garumu?
Sāciet ar vienu pašu noderīgu aicinājumu un uztveriet katru aizvēršanu kā derīgu lēmumu. Tādējādi proaktīva Chatbot uzruna kļūst par labi kontrolētu servisa funkciju – nevis par kārtējo traucēkli tīmekļa vietnē.
Avoti un saistītie standarti
Pārvērtiet vietnes apmeklējumus par labākām sarunām
Iegūstiet vairāk kvalificētu leadu bez papildu šķēršļiem
Izmantojiet ChatReact, lai atbildētu uz nodomu bagātiem jautājumiem, kvalificētu apmeklētājus reālā laikā un virzītu viņus uz demo, piedāvājumiem vai rezervācijām.
Saistītie raksti
Turpināt lasīt

DI čatbota analītikas izveide, ievērojot datu minimizēšanu: notikumi, izlase un glabāšana
Kā mērīt čatbota kvalitāti ar minimāliem notikumiem, kontrolētām sarunu izlasēm, nošķirtiem datu līmeņiem un pārskatāmiem dzēšanas termiņiem.

Piekkļūjamais AI tēlkātbots: WCAG kontrolsaraksts tīmekļa vietnēm
AI tēlkātbots palīdz tikai tad, ja to var izmantot visi. Šis WCAG orientētais kontrolsaraksts norāda, kam tīmekļa vietņu komandām jāpievērs uzmanība, strādājot ar vidžetiem, dialogiem, tastatūras vadību, mobilajām ierīcēm un pāreju uz atbalsta dienestu.
Kā pievienot AI tērzēšanas robotu tīmekļa vietnei, nekaitējot UX vai SEO
Ieviešanas plāns tērzēšanas robota pievienošanai Jūsu vietnei, saglabājot lietotāja ceļojumu, lapas ātrumu un satura struktūru labā stāvoklī.