[aerogear-dev] Storing the payload of the push notification

Thu Feb 5 17:25:33 EST 2015

On Thu, Feb 5, 2015 at 9:24 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2015-01-30, Matthias Wessendorf wrote:
> > Hi,
> >
> > earlier this week there was some discussion about storing the payload of
> > the push notifications ([1]).
>
> Hi Matthias, I think the usage of UPS and how it works is clear to
> everyone here. The focus of the discussion last week was pretty much
> about storing the content of the message.
>
> >
> > Right now, we store some metrics (e.g. client that send the push, number
> of
> > devices, deliveryStatus etc) *and* the entire content of push
> notification.
> > This includes custom key/value pairs, the name of the sound file or even
> > the size of the badge.
> >
> > Is all of that, storing the entire push notification payload really
> needed?
> > *No!*
> >
> > What do we need, and why?
> >
> > For counting the number of sent pushes (over time), the metrics are good
> > enough. We do *NOT* need any of the push content for that, that's
> correct!
> >
> > But we want to do more on the 1.1.0 release. We want to introduce some
> > analytic features, to give our app developers (our users) a better
> > understanding of their push usage (see [2]).
>
> You don't need the content of the message unless we're planning a
> recommendation system or crunching data for some good reason. But we
> already discussed about it.
>

yes, one reason is the planed feature to see how successful a push was.
Perhaps later A/B testing.

Another reason to store the alert is also a convenience for the
app-developer. He can simply see what he sent already out.

>
> >
> > In order to see details on how successful a push was (or not), we need to
> > only store the value of the alert key:
> >
> https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png
> >
> > Ok, let's change that (see [3])!
> >
> > For our app developers, using the UPS to reach out to their mobile app
> > users ("user engagement"), it's important to understand which push was
> more
> > successful:
> >
> >    - "Get 10% discount today" (sent on a Monday)
> >    - "Our shop got new site, check it out and get 5% discount" (sent on a
> >    Friday)
> >
> > With the upcoming analytics we can help them to improve usage of their
> app.
> > User interaction is very important to a successful mobile application and
> > push is a key driver here! Our app developers want an app that is
> actively
> > used by their users (Nobody wants his app sitting on the last page of the
> > device or, even worse, in a folder together with Apple-Maps). Therefore
> > it's critical for our app developers to understand the relevance of their
> > push messages sent and how it impacts the usage of their app. That's why
> we
> > do the analytics described in [2]. And, yes - only the alert, not the
> > entire payload is needed for that.
>
> Yes, only the alert, not the entire payload.
>
> > <https://gist.github.com/matzew/b6459083f39394a892c5#privacy>Privacy
> >
> > On the mentioned PR there was also some discussion about privacy
> violations
> > and stuff, when we store the content of the notification. An example
> where
> > *sensitive* data was sent over push was given. Something like: "Dear Mr.
> > Joe, your blood donation appointment was scheduled for 3 p.m"
> >
> >    1. This is not how push notifications are used for mobile apps. Push
> is
> >    to signal, not carry actual (sensitive) data around.
> >    2. In a lot of countries, at least almost all European countries, you
> >    are not even allowed, by EU law, to give "data" to 3rd party providers
> >    (like the push-networks of Microsoft, Apple or Google).
>
> Yes my friend, a knife for me is to cut tomatoes, for other people
> outside is to hurt. What you gonna do with data pretty much depends.
>

right, the same is generally true. The app-developer can store the alert
(or even the entire payload) directly from his backend, including other
'sensitive' data. He does not need the UnifiedPush Server for that.

Storing the alert gives the app-developer options to learn more about user
engagement and if a (marketing) push was successful.

>
> >
> > How does the actual (sensitive) data come to an app?
> >
> > As said above a push is used to signal/ping an app, to indicate that
> there
> > is real data for the mobile app user. In the background the mobile app
> > tries to connect to the backend of the company, running/maintaining the
> > mobile app. After the real data was fetched, "local notifcations" are
> used
> > to give the user a visible notification, like "Dear Mr. Joe, your blood
> > donation appointment was scheduled for 3 p.m", or simply "New appointment
> > scheduled".
> >
> > If the app was a chat system (and not a blood donation app from the Red
> > Cross), it would be the same: After a signal, the app connects to "chat
> > server" and receives the actual chat message from there. A reply would go
> > over the same "chat server" connection. None of this would go over a 3rd
> > party push network provider like Google, Microsoft or Apple.
> >
> > What would we store from these silent notifications?
> >
> > Nothing, since there is no alert, we would just store the metrics (e.g.
> > client that send the push, number of devices, deliveryStatus etc). If the
> > signaling is actually done with an alert (e.g. alert:"you got a new Chat
> > text" or "New appointment scheduled"), we would store that.
> >
> > I hope this helps a bit to understand what is stored and also why we do
> > need a little bit of information.
>
> Is not clear for me if you still need the content of the message and why.
>

As said above for the planed analytic feature (AGPUSH-971), where the
app-developer can see if his push ("Alert 1") was useful or not.

>
> >
> > BTW. our documentation already says that push is used for signaling, not
> > carrying actual data around, but based on this email I will update it to
> > have explicit information on best practices. Also, the documentation will
> > be clear about what (the alert only) is stored by the UPS, and why. (see
> > [4])
>
> If we provide a clear and solid policy explaining why we need such kind
> of data. I think is totally acceptable.
>

yup, agree

> >
> > Greetings,
> >
> > Matthias
> >
> >    - [1]
> https://github.com/aerogear/aerogear-unifiedpush-server/pull/478
> >    - [2] https://issues.jboss.org/browse/AGPUSH-971
> >    - [3] JIRA TO CREATE: to only store ALERT and not the full payload
> >    - [4] JIRA TO CREATE: update doc regarding push message storage and
> best
> >    practices
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
>
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150205/cc05a17f/attachment-0001.html 