Så skiljer du långsamma svar från kundbortfall i en AI-chattprodukt

Ett tidsintervall är lätt att mäta, men det förklarar inte vad som hände under tiden. Någon kan ha valt att återkomma senare; en avisering kanske inte nådde enheten; appen kanske inte registrerade att en uppgift slutförts; eller så finns det helt enkelt ingen ny åtgärd att observera. Dessa möjligheter kräver olika produktåtgärder, så om de slås ihop under en enda etikett som ”inaktiv” blir det svårare att tolka de underliggande uppgifterna.

Meddelandesystem skiljer själva mellan leveransstadier. Firebase Cloud Messaging redovisar skickade meddelanden, mottagning i Android-appen, visningar av aviseringar och öppningar som separata mått. En skickad avisering kan innebära att meddelandet köats eller skickats vidare till en tjänst som APNs, inte att en person har sett det. Firebase påpekar också att viss rapportering är fördröjd och att den aggregerade leveransdatan har begränsad täckning. Firebase: Förstå meddelandeleverans

Den här skillnaden pekar på en användbar analysregel: dra aldrig slutsatser om en persons svarstakt utifrån en tidigare händelse, som en begäran om att skicka ett meddelande, och betrakta aldrig en utebliven öppning eller ett uteblivet svar som bevis på att leveransen misslyckades. Registrera det produkten kan observera och låt ouppmärksammade utfall förbli okända.

Erbjud en enkel, valfri inställning som besvarar en praktisk fråga: när vill personen att produkten ska be om ett svar eller följa upp? Använd begripliga alternativ som ”när jag är redo”, ”senare i dag” eller ”påminn mig en dag jag väljer”, om de passar produkten. De exakta alternativen är ett designbeslut, inte ett påstående om vad en viss användare föredrar.

Spara valet som en användarpreferens med tidpunkten då den uppdaterades och, där det är relevant, ett utgångsdatum eller ett slutvillkor. En preferens är varaktig kontext om hur personen själv valt att använda produkten; ett svarsintervall är en uppgift om en viss konversation eller ett visst meddelande. Analysplattformar gör en liknande åtskillnad mellan användaregenskaper, som beskriver en användare, och händelseegenskaper, som beskriver en specifik åtgärd. Amplitude: Användaregenskaper och händelseegenskaper

Gör det enkelt att ändra eller ta bort preferensen. Omvandla inte observerade genomsnittliga svarstider till antagna preferenser: ett historiskt mönster kan beskriva tidigare beteende, men bara ett uttryckligt val visar en uttalad preferens. Om det inte finns någon sparad preferens ska värdet anges som okänt i stället för att du tilldelar personen en standardtakt.

Definiera ett litet antal uppgiftstillstånd utifrån åtgärder som systemet kan verifiera. Till exempel: waiting_for_user, waiting_for_service, ready_for_user, completed och cancelled. Använd ett tillstånd bara när en händelse eller systemrespons ger stöd för det. När en användare skickar ett meddelande kan uppgiften övergå till waiting_for_service; ett lyckat svar kan göra den ready_for_user; en uttrycklig slutförandeåtgärd kan markera den som completed. Om ett svar eller en tillståndsuppdatering misslyckas ska du registrera felet och låta uppgiften förbli olöst tills en senare händelse klargör den.

Koppla en identifierare för konversationen eller uppgiften till dessa händelser så att en analytiker kan återskapa förloppet. Registrera händelsetid, händelsetyp, aktuellt uppgiftstillstånd och relevant tekniskt utfall. Håll preferenser på användarnivå åtskilda från detaljer för enskilda uppgifter: ”föredrar att svara när jag är redo” kan gälla flera konversationer, medan ”den här uppgiften väntar på en åtgärd från användaren” beskriver en pågående interaktion. I händelsebaserad analys fångar händelseegenskaper kontexten vid tidpunkten för en åtgärd, medan användaregenskaper beskriver attribut som kan förändras över tid. Amplitude: Användaregenskaper och händelseegenskaper

Den här åtskillnaden skyddar också den historiska tolkningen. När någon ändrar en preferens ska du bevara det gamla värdet för tidigare händelser och använda det nya för senare händelser; skriv inte om historiken som om den nya preferensen alltid hade gällt. Amplitudes dokumentation beskriver detta tidsmedvetna beteende för användaregenskaper. Amplitude: Användaregenskaper och händelseegenskaper

För varje utgående chattmeddelande eller avisering ska du registrera de steg som integrationen faktiskt visar: sändning försökt, godkänt av meddelandetjänsten, levererat till appen om tillgängligt, visat om tillgängligt, öppnat om tillgängligt samt eventuella kända fel. Hitta inte på någon leveransbekräftelse som plattformen inte tillhandahåller. På Apples plattformar hanterar APNs leveransen av fjärraviseringar till användarens enheter; den systemrollen är något annat än en uppgift om att personen öppnade aviseringen. Apple: Användaraviseringar

Använd infrastrukturutfall som infrastruktursignaler. En misslyckad begäran, ett avslag från leverantören, en tidsgräns som löpt ut eller en fördröjd kö bör till exempel leda till en undersökning av leverans- eller tjänstestatus. En lyckad begäran om att skicka ett meddelande är bara belägg för att det steget genomfördes. Firebase förklarar att deras sändningsstatistik kan avse ett meddelande som köats för leverans eller skickats vidare till en annan tjänst, och att deras aggregerade data om Android-transport beskriver breda trender snarare än varje enskilt meddelande. Firebase: Förstå meddelandeleverans

Även kvittenser för intern meddelandebehandling måste tolkas varsamt. Google Cloud Pub/Sub beskriver meddelanden som utestående tills de kvitteras och påpekar att okvitterade meddelanden kan levereras igen när en tidsgräns löper ut; meddelanden kan också levereras mer än en gång. Det påminner om vikten av att utforma händelsebehandling så att den tål dubbletter och skilja en saknad behandlingskvittens från ett uteblivet svar från användaren. Google Cloud: Översikt över prenumerationer

Ett praktiskt beslutsstöd kan hålla etiketterna snäva och grundade i belägg:

Observerade belägg: Personen valde en svarstidspreferens och ingen senare åtgärd har observerats; Lämplig analysåtgärd: Preferens registrerad; svar ännu inte observerat; Vad det inte fastställer: Att personen har lämnat eller att leveransen misslyckades

Observerade belägg: En tjänstebegäran eller ett meddelandesteg i leveransen misslyckades eller överskred en tidsgräns; Lämplig analysåtgärd: Tekniskt problem i det registrerade steget; Vad det inte fastställer: Varför personen inte svarade

Observerade belägg: Produkten har ett bekräftat nästa steg som väntar på en åtgärd från användaren; Lämplig analysåtgärd: Uppgift väntar på åtgärd från användaren; Vad det inte fastställer: Att uppgiften har övergetts

Observerade belägg: En slutförandeåtgärd, avbokning eller annan slutåtgärd har registrerats; Lämplig analysåtgärd: Slutförd eller avbruten, enligt registreringen; Vad det inte fastställer: En bredare bedömning av framtida användning

Observerade belägg: Belägg saknas, är fördröjda eller motsägelsefulla; Lämplig analysåtgärd: Okänt eller behöver stämmas av; Vad det inte fastställer: Någon säker förklaring av beteendet

Etiketten ”kundbortfall” bör kräva en definierad regel på produktnivå och tillräckliga belägg för den regeln; den bör inte vara en synonym för ett långt uppehåll mellan meddelanden. Om en kontrollpanel behöver visa en status innan alla belägg finns är ”inget nyligt svar observerat” mer precist än ett påstående om varför personen är frånvarande. Behandla statusen som preliminär och uppdatera den när fördröjda händelser kommer in.

En användbar kohortanalys undersöker om personer som uttryckligen väljer en långsammare takt slutför sina angivna uppgifter inom en tidsram som stämmer med preferensen. Jämför liknande fall: gruppera efter vald preferens och uppgiftstyp och granska separat leveransfel, olösta tjänstebegäranden och slutförandehändelser. Gör inte en persons tysta period till en signal om att hela produkten misslyckas; leta efter mönster mellan jämförbara uppgifter och leveransförhållanden.

Om en person till exempel väljer ”när jag är redo”, en konversation förblir öppen och produkten inte har registrerat något leveransfel eller någon ny användaråtgärd, är den försvarbara statusen ”inget svar observerat; preferens registrerad; uppgiften fortfarande öppen”. Om ett utgående svar har ett registrerat tjänstefel bör statusen återspegla det felet även om personens preferens också är känd. Detta är ett exempel på en klassificering utifrån händelsemodellen ovan, inte ett uppmätt produktresultat.

Innan du använder ett mått som underlag för beslut bör du kontrollera om händelser anländer sent, förekommer flera gånger eller saknas på vissa plattformar. Firebase uppger att viss leveransrapportering är fördröjd och att aggregerade mått kan utelämna eller avrunda utfall; Pub/Sub beskriver leverans minst en gång och möjliga återleveranser. Stäm av händelser med stabila meddelande- eller uppgiftsidentifierare och undvik att räkna ett nytt försök som en andra användaråtgärd. Firebase: Förstå meddelandeleverans, Google Cloud: Översikt över prenumerationer

Om uppföljning ingår i produkten ska den anpassas efter personens valda preferens. En vald påminnelsetid kan styra en påminnelse; ”när jag är redo” kan innebära att ingen tidsbaserad påminnelse skickas. Ge personen ett tydligt sätt att ändra sitt val och visa det aktuella tillståndet i konversationen så att hen kan se om produkten väntar på hen, väntar på en tjänst eller är klar.

Använd analys för att hitta tekniska brister och förstå när uppgifter slutförs, inte för att skapa säkerhet utifrån tystnad. Uttryckliga preferenser ger sammanhang, uppgiftstillstånd visar vad som återstår och leveranshändelser visar vilka tekniska steg som är kända. När någon av dessa uppgifter saknas ska osäkerheten finnas kvar i etiketten. Det ger en mer användbar bild av långsamma svar och låter samtidigt användaren själv styra när hen återkommer.