I have noticed that if I send push notifications one after the other quite quickly (within around 10-20 secs of each other) the extra information can get 'mixed up'. This was observed using the ETPush SDK on Android and also listening directly to incoming messages using my own BroadcastReceiver. For example when I view the logs from ETPushService as the messages are received I see (amongst other things):

[google.sent_time:1484922340768] [alert:Testing channel_1] [deepLink:channel_1] [google.sent_time:1484922432464] [alert:Testing channel_2] [deepLink:channel_2] [google.sent_time:1484922482915] [alert:Testing channel_3] [deepLink:channel_3] [google.sent_time:1484922517017] [alert:Testing channel_4] [deepLink:channel_4] [google.sent_time:1484922517260] [alert:Testing channel_4] [deepLink:channel_3] [google.sent_time:1484922534682] [alert:Testing channel_2] [deepLink:channel_4] [google.sent_time:1484922548316] [alert:Testing channel_2] [deepLink:channel_4] [google.sent_time:1484922833792] [alert:Testing channel_2] [deepLink:channel_2]

As you can see the value for alert and deepLink do not always match, however when the messages were sent they always went out with "MessageText":"Testing channel_x" and "CustomPayload":{"deepLink":"channel_x"} where channel_x was the same within each message. It seems as if the message data gets mixed up within ExactTarget's service and arrives in the wrong order, but eventually sorts itself out by the final message.

Is this something that anyone has seen before, and are there any known workarounds for this behaviour?


As of the current release:

customPayload is cached for 15 minutes. Wait at least 15 minutes before performing two different customPayload sends to the same PushMessageId.

Marketing Cloud API Documentation

The caching will be removed in an upcoming release.

  • This explains it, when I use different predefined messages without using an override I get the correct data each time, thanks. – user3265561 Jan 20 '17 at 15:53
  • This is a problem commonly seen during testing/development but not typically a real-world use-case. Regardless, stay tuned, it will be fixed very shortly. – Bill Mote Jan 20 '17 at 16:40
  • Ah it was found during some particularly spammy testing, I think 15 mins will be fine during real world use. – user3265561 Jan 20 '17 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.