<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 9:24 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 2015-01-30, Matthias Wessendorf wrote:<br>
> Hi,<br>
><br>
> earlier this week there was some discussion about storing the payload of<br>
> the push notifications ([1]).<br>
<br>
</span>Hi Matthias, I think the usage of UPS and how it works is clear to<br>
everyone here. The focus of the discussion last week was pretty much<br>
about storing the content of the message.<br>
<span class=""><br>
><br>
> Right now, we store some metrics (e.g. client that send the push, number of<br>
</span>> devices, deliveryStatus etc) *and* the entire content of push notification.<br>
<span class="">> This includes custom key/value pairs, the name of the sound file or even<br>
> the size of the badge.<br>
><br>
> Is all of that, storing the entire push notification payload really needed?<br>
</span>> *No!*<br>
<span class="">><br>
> What do we need, and why?<br>
><br>
> For counting the number of sent pushes (over time), the metrics are good<br>
</span>> enough. We do *NOT* need any of the push content for that, that's correct!<br>
<span class="">><br>
> But we want to do more on the 1.1.0 release. We want to introduce some<br>
> analytic features, to give our app developers (our users) a better<br>
> understanding of their push usage (see [2]).<br>
<br>
</span>You don't need the content of the message unless we're planning a<br>
recommendation system or crunching data for some good reason. But we<br>
already discussed about it.<br></blockquote><div><br></div><div>yes, one reason is the planed feature to see how successful a push was. Perhaps later A/B testing.</div><div><br></div><div>Another reason to store the alert is also a convenience for the app-developer. He can simply see what he sent already out. <br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
><br>
> In order to see details on how successful a push was (or not), we need to<br>
> only store the value of the alert key:<br>
> <a href="https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png" target="_blank">https://aerogear.org/docs/unifiedpush/aerogear-push-ios/img/PushMessage.png</a><br>
><br>
> Ok, let's change that (see [3])!<br>
><br>
> For our app developers, using the UPS to reach out to their mobile app<br>
> users ("user engagement"), it's important to understand which push was more<br>
> successful:<br>
><br>
</span>> - "Get 10% discount today" (sent on a Monday)<br>
> - "Our shop got new site, check it out and get 5% discount" (sent on a<br>
<span class="">> Friday)<br>
><br>
> With the upcoming analytics we can help them to improve usage of their app.<br>
> User interaction is very important to a successful mobile application and<br>
> push is a key driver here! Our app developers want an app that is actively<br>
> used by their users (Nobody wants his app sitting on the last page of the<br>
> device or, even worse, in a folder together with Apple-Maps). Therefore<br>
> it's critical for our app developers to understand the relevance of their<br>
> push messages sent and how it impacts the usage of their app. That's why we<br>
> do the analytics described in [2]. And, yes - only the alert, not the<br>
> entire payload is needed for that.<br>
<br>
</span>Yes, only the alert, not the entire payload.<br>
<br>
> <<a href="https://gist.github.com/matzew/b6459083f39394a892c5#privacy" target="_blank">https://gist.github.com/matzew/b6459083f39394a892c5#privacy</a>>Privacy<br>
<span class="">><br>
> On the mentioned PR there was also some discussion about privacy violations<br>
> and stuff, when we store the content of the notification. An example where<br>
</span>> *sensitive* data was sent over push was given. Something like: "Dear Mr.<br>
<span class="">> Joe, your blood donation appointment was scheduled for 3 p.m"<br>
><br>
</span>> 1. This is not how push notifications are used for mobile apps. Push is<br>
<span class="">> to signal, not carry actual (sensitive) data around.<br>
</span>> 2. In a lot of countries, at least almost all European countries, you<br>
<span class="">> are not even allowed, by EU law, to give "data" to 3rd party providers<br>
> (like the push-networks of Microsoft, Apple or Google).<br>
<br>
</span>Yes my friend, a knife for me is to cut tomatoes, for other people<br>
outside is to hurt. What you gonna do with data pretty much depends.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Storing the alert gives the app-developer options to learn more about user engagement and if a (marketing) push was successful. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
><br>
> How does the actual (sensitive) data come to an app?<br>
><br>
> As said above a push is used to signal/ping an app, to indicate that there<br>
> is real data for the mobile app user. In the background the mobile app<br>
> tries to connect to the backend of the company, running/maintaining the<br>
> mobile app. After the real data was fetched, "local notifcations" are used<br>
> to give the user a visible notification, like "Dear Mr. Joe, your blood<br>
> donation appointment was scheduled for 3 p.m", or simply "New appointment<br>
> scheduled".<br>
><br>
> If the app was a chat system (and not a blood donation app from the Red<br>
> Cross), it would be the same: After a signal, the app connects to "chat<br>
> server" and receives the actual chat message from there. A reply would go<br>
> over the same "chat server" connection. None of this would go over a 3rd<br>
> party push network provider like Google, Microsoft or Apple.<br>
><br>
> What would we store from these silent notifications?<br>
><br>
> Nothing, since there is no alert, we would just store the metrics (e.g.<br>
> client that send the push, number of devices, deliveryStatus etc). If the<br>
> signaling is actually done with an alert (e.g. alert:"you got a new Chat<br>
> text" or "New appointment scheduled"), we would store that.<br>
><br>
> I hope this helps a bit to understand what is stored and also why we do<br>
> need a little bit of information.<br>
<br>
</span>Is not clear for me if you still need the content of the message and why.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
><br>
> BTW. our documentation already says that push is used for signaling, not<br>
> carrying actual data around, but based on this email I will update it to<br>
> have explicit information on best practices. Also, the documentation will<br>
> be clear about what (the alert only) is stored by the UPS, and why. (see<br>
> [4])<br>
<br>
</span>If we provide a clear and solid policy explaining why we need such kind<br>
of data. I think is totally acceptable.<br></blockquote><div><br></div><div>yup, agree</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
><br>
> Greetings,<br>
><br>
> Matthias<br>
><br>
> - [1] <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/478" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/478</a><br>
> - [2] <a href="https://issues.jboss.org/browse/AGPUSH-971" target="_blank">https://issues.jboss.org/browse/AGPUSH-971</a><br>
> - [3] JIRA TO CREATE: to only store ALERT and not the full payload<br>
> - [4] JIRA TO CREATE: update doc regarding push message storage and best<br>
<span class="">> practices<br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
</span><span class="">> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
</span>--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
<div class=""><div class="h5">_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</div></div>