Under årtionden har SMS varit en tillförlitlig, men extremt
tyst, kanal. Du skickar ett meddelande och du får (förhoppningsvis) en
leveransbekräftelse (”Delivered”) från operatören – men därefter är
det en ”black box”. Har kunden faktiskt öppnat meddelandet? Håller de
på att svara just nu? Med den äldre SMS-tekniken saknas helt verktygen för att
svara på detta.
Här representerar RCS (Rich Communication Services) ett massivt teknikkliv. Istället för envägskommunikation över det åldrande GSM-nätet bygger RCS på IP-baserad teknologi. Inom affärskommunikation (MaaP – Messaging as a Platform) ger detta företag tillgång till interaktion i realtid, som läskvitton (Read) direkt via asynkrona webhooks.
I denna guide går vi igenom hur du implementerar realtids-events och varför de är en nyckelkomponent för framtidens kundkommunikation.
Varför läskvitton är en statistisk Game Changer
När man utvärderar en traditionell SMS-kampanj är ”Levererat” ofta det enda pålitliga mätvärdet för räckvidd. För att mäta genuint engagemang har marknadsförare och analytiker tvingats förlita sig på klickfrekvenser (CTR) på bifogade länkar.
Med RCS introduceras en helt ny, avgörande KPI för mobilkommunikation: Öppningsgrad (Read Rate).
Genom att veta exakt när och om ett meddelande faktiskt har lästs kan företag:
Mångdubbla precisionen i A/B-testning av budskap och erbjudanden.
Identifiera vilka exakta tider på dygnet olika målgrupper är mest mottagliga.
Följa upp missade läskvitton via andra kanaler, vilket minimerar spam-känslan för de som redan läst informationen.
Så fungerar asynkrona Webhooks för RCS
För att leverera dessa händelser utan dröjsmål används
asynkrona webhooks. Istället för att ditt system konstant ska behöva fråga vår
server om nya statusar (”polling”), meddelar vi dig direkt. Du
registrerar en URL (din webhook-endpoint) hos oss. Så fort en användare läser
ett meddelande eller börjar skriva, skickar vi omedelbart en HTTP
POST-förfrågan (callback) med relevant data till din server.
Exempel på JSON-payloads
När kunden öppnar meddelandet skickas en payload med statusen READ.
Payload för Läskvitto (Read)
{
"messageId": "65e15d14f1234547890ghijkl",
"bundleId": "65eb3d14f1234567890abcdef",
"conversationId": "65e15d14f1234547890ghijkl",
"code": 204,
"duration": 1,
"created": "0001-01-01T00:00:00",
"fallback": {
"fallbackPolicy": "FallbackOnNoCapability, FallbackAfterTimeout",
"fallbackTimeout": 500,
"fallbackMessage": "Detta är ett fallback-meddelande",
"fallbackStatus": "Pending",
"fallbackReason": "FallbackOnNoCapability"
}
}Kodexempel: Ta emot en Webhook
Att ta emot dessa asynkrona händelser är enkelt. Nedan följer ett exempel på hur en typisk webhook-controller kan byggas i C# för att ta emot, tolka och logga dessa värdefulla KPI:er.
using Microsoft.AspNetCore.Mvc;
using System;
[ApiController]
[Route("api/rcs/webhooks")]
public class RcsWebhookController : ControllerBase
{
private readonly ILogger<RcsWebhookController> _logger;
public RcsWebhookController(ILogger<RcsWebhookController> logger)
{
_logger = logger;
}
[HttpPost("events")]
public IActionResult ReceiveReadCallback([FromBody] RcsReadCallbackPayload payload)
{
// Kontrollera om statuskoden motsvarar Läst (Code 204)
if (payload.Code == 204)
{
_logger.LogInformation("Meddelande {MessageId} i konversation {ConversationId} har markerats som LÄST.",
payload.MessageId, payload.ConversationId);
// TODO: Uppdatera meddelandestatus och lässtatistik (KPI) i er databas
}
// VIKTIGT: Returnera alltid HTTP 200 OK snabbt för att undvika retries
return Ok();
}
}
// DTO-klasser anpassade för RCS API:ets läskvitto-payload
public class RcsReadCallbackPayload
{
public string MessageId { get; set; }
public string BundleId { get; set; }
public string ConversationId { get; set; }
public int Code { get; set; }
public int Duration { get; set; }
public DateTime Created { get; set; }
public FallbackDetails Fallback { get; set; }
}
public class FallbackDetails
{
public string FallbackPolicy { get; set; }
public int FallbackTimeout { get; set; }
public string FallbackMessage { get; set; }
public string FallbackStatus { get; set; }
public string FallbackReason { get; set; }
}3 Best Practices vid hantering av Webhooks
Svara blixtsnabbt (HTTP 200 OK): Din endpoint bör returnera ett ”OK” omedelbart. Undvik att göra tunga databasanrop synkront under samma request. Om en databasuppdatering tar för lång tid, kan vårt system tro att leveransen misslyckades och försöka skicka webhooken på nytt. Lägg istället tunga uppgifter i ett bakgrundsjobb.
Idempotent hantering: Nätverk är oförutsägbara och ibland kan samma event råka triggas två gånger. Använd det unika eventId som skickas i payloaden för att garantera att ni inte loggar samma läskvitto mer än en gång.
Bygg broar mellan IT och Marknad: Låt inte denna data stanna i serverloggarna. Se till att Read Rates matas rakt in i era CRM-system eller marknads-dashboards, så att er verksamhet verkligen kan kapitalisera på den ökade insikten.
Sammanfattning
Med introduktionen av Real-time Events raderar RCS den gamla osäkerheten kring vad som händer efter att kommunikationen lämnat servern. Att veta om en kund de facto läst ett erbjudande, eller att i realtid se när de formulerar en fråga till kundtjänsten, flyttar hela B2C-dialogen från statiska utskick till äkta konversationer.
Genom en korrekt integrerad webhook för Read får ni inte bara kontroll på datan, ni säkerställer att ni maximerar potentialen i nästa generations mobilkommunikation.