Les notificacions push són una eina de màrqueting vital per a qualsevol persona amb una aplicació mòbil.
És la millor manera de comunicar-se amb els seus usuaris, enviant missatges urgents als seus telèfons mòbils.
Una aplicació mòbil pot enviar a un usuari una notificació push, que és un missatge emergent breu que apareix al seu telèfon intel·ligent fins i tot quan l'aplicació no està oberta.
Aquestes alertes poden incloure recordatoris, actualitzacions, descomptes i molt més.
Estan creats per cridar l'atenció dels usuaris. El títol, el missatge, la imatge i l'URL són components possibles d'una notificació push. Els emojis, els logotips i altres coses també poden formar part d'ells.
Els sistemes operatius com Apple OS i Google Android tenen diverses interfícies per a les notificacions push.
Les notificacions push es poden utilitzar per promoure la implicació, augmentar l'ús d'aplicacions, afectar les conversions i molt més.
Les opcions són realment il·limitades.
Les notificacions push per a dispositius mòbils, també conegudes com a notificacions push per a dispositius mòbils, poden complementar el vostre ús de canals com el correu electrònic, els SMS i les notificacions push en línia amb una sèrie d'avantatges especials.
Rebràs una descripció ràpida del servei de notificacions en aquesta publicació i informació sobre el seu objectiu, disseny d'alt nivell, característiques especials i molt més.
Objectiu
Desenvolupar un servei de notificació que pugui distribuir de manera eficient missatges de producte a usuari a través de diversos canals
Requisits:
- API d'enviament: publiqueu un punt final autoritzat perquè qualsevol backend i microservei pugui començar a lliurar notificacions.
- Canals compatibles: admet l'enviament d'alertes a qualsevol canal que publiqui una API, com ara correu electrònic, missatge de text i push.
- Preferències de l'usuari: permet als usuaris seleccionar les seves preferències d'usuari per a cada canal i notificació.
- Límits per al compliment del servei aigües avall: eviteu tenir el vostre correu electrònic o servei d'SMS accelerat o aturat.
- Escalable: permet (teòricament) escala horitzontal infinita.
Arquitectura d'alt nivell
Suposem que el vostre codi ha de notificar algú:
- El vostre codi invoca el punt final POST /send. Per a cada canal disponible, la sol·licitud inclou l'ID d'usuari del destinatari, el tipus de notificació i el seu contingut.
- El punt final /send utilitza el flux de credencials del client OAuth2 per autenticar la sol·licitud.
- Les opcions de notificació de l'usuari es demanen a la base de dades. Les preferències mostren si l'usuari està subscrit o no a un determinat canal i notificació.
- Des de la base de dades, llegirà les característiques de l'usuari com adreces de correu electrònic i números de telèfon.
- Aquest punt final crearà un objecte de missatge que inclou les característiques de l'usuari, els canals i el contingut específic del canal. Tanmateix, no inclourà canals desactivats. A continuació, el missatge s'envia a un servei de ventilació.
- Els missatges entrants es difonen a les cues de treball mitjançant el servei de fanout. Tanmateix, hi ha un filtratge per ignorar les cues de treball dels canals que no s'especifiquen al missatge.
- Cada canal té un processador i una cua de treball. El processador assumeix la tasca i després demana el servei adequat, com ara un correu electrònic transaccional o un servei d'SMS.
Principals elements arquitectònics
POST/enviat
És possible que hagis notat que només l'identificador d'usuari i ni l'adreça de correu electrònic ni el número de telèfon s'inclouen a la sol·licitud a aquest punt final. Això permet que els serveis de notificació romanguin anònims per als usuaris.
Per garantir l'escalabilitat, el punt final es col·loca darrere d'a balanç de càrrega.
L'autenticació típica de cara a l'usuari no proporciona protecció per al punt final.
Heu d'utilitzar un mètode d'autenticació diferent conegut com a flux de credencials de client OAuth2 que s'utilitza per a la comunicació de servidor a servidor, ja que el servei que envia la sol·licitud és el programari mateix.
La vostra aplicació proporcionarà notificacions en molts llocs diferents. Podeu utilitzar la funció d'enviament gairebé a qualsevol lloc, com ara des d'una base de codi nova o el vostre flux de treball de creació, implementant-lo com a punt final darrere d'un equilibrador de càrrega, que garanteix que sigui escalable de manera independent.
PUT/preferències d'usuari
Utilitzeu un parell clau/valor o una base de dades NoSQL que sigui extremadament escalable. Formateu els registres de la següent manera: CLAU: identificador d'usuari de mostra: identificador de notificació de mostra, VALOR: [“correu electrònic”, “estat: cert”, “SMS”, “estat: fals”, canal: “correu electrònic”, “correu electrònic”, estat : cert”]
Si hi ha valors "falsos" als registres, el punt final de transmissió exclourà el canal corresponent del missatge lliurat al fanout. Si no hi ha cap registre per a un canal, l'usuari no ha indicat expressament les seves preferències. Heu de consentir per defecte en aquest escenari.
L'usuari pot modificar les dades de la base de dades de preferències de l'usuari mitjançant la vostra interfície d'usuari i un punt final normal que està assegurat pels vostres procediments d'autenticació estàndard.
Els usuaris s'irritaran i es veuran obligats a designar les vostres alertes com a correu brossa o a silenciar-les si no els proporcioneu l'opció d'alterar les seves preferències de notificació. Com a resultat, la vostra experiència d'usuari es veurà perjudicada encara més i els serveis d'enviament de correu electrònic o SMS podrien suspendre el vostre compte.
Fan Out
Fanout copia un missatge i el distribueix a diferents ubicacions. Són assequibles i molt escalables. Utilitzeu SNS a AWS. Utilitzeu Pub/Sub a Azure i temes i subscripcions a Google Cloud Platform.
Per evitar l'enviament de missatges inútils a les cues de treball de canals exclosos, podeu configurar el filtratge entre el fanout i les cues de treball. Per exemple, a AWS SNS, podeu especificar que la cua de treballs de correu electrònic només hauria de rebre el missatge de distribució si té el valor "correu electrònic" al camp "canals".
Fins i tot si podríeu crear codi per enviar el missatge idèntic a les cues de treball necessàries, el fanout és més eficient i requereix menys codificació. Fanout també ofereix la comoditat d'afegir i eliminar cues, cosa que us permet ampliar i reorganitzar els vostres canals.
Tramitació de treballs
Els missatges s'emmagatzemen en cues pendents de processament pels processadors de treballs. També són assequibles i molt escalables. Els processadors de treballs són fragments de codi que processen missatges de les cues de treballs. En funció del volum de missatges de la cua, es poden escalar.
El processador de treballs hauria de fer una trucada API al proveïdor adequat per enviar l'avís en el nostre escenari mitjançant un servei de correu electrònic transaccional.
La majoria de proveïdors d'enviament de missatges de correu electrònic, SMS i similars tenen requisits estrictes per a la quantitat i el calibre dels missatges que envieu. A més, voleu examinar-los i configurar els procediments adequats a fons. Aquests són els nostres consells sobre com evitar que se us cancel·li l'AWS SES.
Podeu definir un nombre màxim de processadors de treballs per evitar que es superin els límits de tarifes dels serveis de lliurament.
Més millores
Podeu fer una ullada a un munt d'aquests articles.
- Necessiten les seves pròpies API, taules, etc. per tenir un servei de notificació escalable dins de l'aplicació.
- Recollida i mostra de l'informe obert/clic
- Eliminar el contingut de les notificacions del codi i deixar que el vostre equip de producte i disseny modifiqui les alertes de manera visual, en lloc d'això, sense canviar el codi.
- Sense canviar cap codi, el vostre equip pot utilitzar el tauler per activar o desactivar les notificacions de determinats canals.
Beneficis de la notificació push
- Augmenta la interacció de l'usuari: les actualitzacions i el material fresc mantindran els teus usuaris interessats.
- Augmenta la visibilitat de la comunicació: assegureu-vos que els vostres missatges es rebin immediatament, fins i tot quan la gent no estigui activa. Envieu notificacions urgents i proporcioneu als usuaris una experiència fluida.
- Mantenir la retenció: utilitzeu notificacions push que siguin clarament visibles per instar els usuaris a tornar. Podeu augmentar la retenció d'usuaris i reduir l'abandonament empenyent els clients de nou al vostre lloc web i aplicació.
- Millorar les conversions: en crear campanyes push al voltant de premis, promocions, descomptes o altres ofertes a l'aplicació, podeu augmentar les vendes.
- Amplieu la vostra empresa: el vostre enfocament de comunicació ha d'escalar a mesura que el vostre públic s'amplia. A mesura que la vostra base de clients s'amplia, les notificacions push són un mètode eficaç per mantenir-vos en contacte amb ells.
- Feu que l'experiència de l'usuari estigui connectada (UX): en proporcionar alertes transaccionals als consumidors per mantenir-los informats i oferir una experiència fluida entre canals, podeu reduir la fricció durant el recorregut del client.
Conclusió
En conclusió, vam obtenir coneixements sobre l'arquitectura d'un servei de notificació push escalable. També vam analitzar les eines que proporcionen tots els principals proveïdors de serveis al núvol perquè pugueu basar les vostres notificacions en aquestes.
Malgrat que vaig fer tot el possible per oferir-vos una visió general de l'arquitectura del sistema de notificacions push, hi ha moltes més coses darrere de les escenes.
Espero sincerament que aquesta informació us sigui útil i que en feu un bon ús.
Deixa un comentari