Queste informazioni possono essere utili per risolvere eventuali problemi dei messaggi push.
I seguenti tipi di ritardo possono essere associati ai messaggi push per Mobile Services:
Attesa degli hit di Analytics
Per ogni suite di rapporti, un’impostazione consente di determinare quando elaborare gli hit di Analytics in arrivo. L’impostazione predefinita è ogni ora.
L’effettiva elaborazione degli hit di Analytics potrebbe richiedere fino a 30 minuti, ma in genere dura 15-20 minuti. Ad esempio, una suite di rapporti elabora gli hit ogni ora. Considerando il tempo massimo di elaborazione richiesto (30 minuti), potrebbero essere necessari fino a 90 minuti perché un hit in arrivo sia disponibile per un messaggio push. Se un utente ha avviato l’app alle 09:01, l’hit risulterebbe nell’interfaccia di Mobile Services come nuovo utente unico tra le 10:15 e le 10:30.
Attesa del servizio push
Il servizio push (APNS o GCM) potrebbe non inviare subito il messaggio. Anche se raramente, sono stati registrati casi con tempi di attesa di 5-10 minuti. Puoi controllare se il messaggio push è stato inviato al servizio push guardando la vista Rapporto del messaggio push, individuando il messaggio nella tabella Cronologia messaggio e visualizzando il dato Pubblicato.
Questo dato corrisponde al numero di invii ai servizi push con esito positivo. I servizi push non garantiscono al 100% l’effettivo invio di un messaggio.
Per maggiori informazioni sull’affidabilità del servizio, vedi:
Chiave API non valida
La chiave API potrebbe non essere valida per i motivi seguenti:
Determinare la validità di una chiave API
Per determinare la validità di una chiave API, esegui il comando seguente:
Android
# api_key=YOUR_API_KEY
#curl--header"Authorization:key=$api_key"\
--headerContent-Type:"application/json"\
https://gcm-http.googleapis.com/gcm/send\
-d"{\"registration_ids\":[\"ABC\"]}"
Se viene restituito un codice di stato HTTP 401 la chiave API non è valida. Altrimenti, il risultato visualizzato sarà simile al seguente:
{"multicast_id":6782339717028231855,"success":0,"failure":1,
canonical_ids":0,"results":[{"error":"InvalidRegistration"}]}
Per controllare la validità di un token di registrazione, sostituisci "ABC"
con il token.
Il certificato APNS potrebbe non essere valido per i motivi seguenti:
.p8
invece di un file .p12
.Un esempio
L’esempio seguente illustra come risolvere un errore push quando usi una VRS.
Il cliente seguente ha due app iOS:
a.appid contains “PhotoShop_iOS_app_SF”
a.os contains “iOS”
In questo esempio, se un dipendente Photoshop invia un messaggio push all’app PhotoShop_iOS_app_SF, tutti gli utenti dell’app PhotoShop_iOS_app_SF riceveranno normalmente il messaggio push. Tuttavia, se il dipendente invia un messaggio all’app PhotoShop_iOS_app_LA, poiché il relativo Segmento di definizione VRSID non è corretto (iOS
anzichéa.os contains "PhotoShop_iOS_app_LA"
), il messaggio viene inviato a tutti gli utenti iOS in AllAdobe PhotoShop_apps. Nonostante venga inviato agli utenti di PhotoShop_iOS_app_LA, questo messaggio inserisce nella blocklist gli ID push per gli utenti di PhotoShop_iOS_app_SF poiché l’app PhotoShop_iOS_app_SF dispone di un certificato diverso. Se il segmento fosse stato definito come a.os contains “PhotoShop_iOS_app_LA”
, il messaggio push sarebbe stato inviato solo agli utenti PhotoShop_iOS_app_LA.
Se passati con il certificato push PhotoShop_IOS_app_LA, gli identificatori push di PhotoShop_iOS_app_SF verrebbero restituiti come invalid
.
Quando crei un messaggio push per un’app che utilizza una VRS e fai clic su Salva e invia, viene visualizzato un avviso che ti ricorda di verificare che ogni app indicata deve avere un certificato valido. Se ogni app non dispone di un certificato valido, i segmenti di pubblico potrebbero essere inseriti nella blocklist a tempo indefinito e in futuro non sarebbe possibile inviare messaggi push agli utenti in questione. Per ulteriori informazioni sui segmenti di pubblico, vedi Pubblico: definire e configurare le opzioni relative al pubblico per i messaggi push.