Referrer improvements #83
Conversation
@d4rken I think it's a brliant idea! Didn't knew about this |
|
|
||
| <application> | ||
| <receiver | ||
| android:name=".InstallReferrerReceiver" |
There was a problem hiding this comment.
This part might be mentioned in readme.
There was a problem hiding this comment.
So the dev is aware that Piwik registers a broadcastreceiver? Or in case the dev wants to register this receiver himself? We could rebroadcast the intent to allow registering multiple receivers for this intent.
There was a problem hiding this comment.
nvm, I thought that devs have to declare it explicitly in theirs apps AndroidManifest.xml
|
@d4rken Piwik should be proud that have contributor like You 👍 Let me know when You are ready, I'll look at code once again. |
|
I'm not satisfied with how the download tracking is deferred, i.e. it being a fixed timer, but I don't have a better idea. It works, it's low impact, just seems dirty... |
|
The broadcast receiver now forwards the intent instead of consuming. |
…ic and we can't support the edge cases. * Removed ExtraIdentifier.INSTALLER_PACKAGENAME which was also too specific and not suitable for detailing download information. It was attached as REFERRER field anyways. * Fixed REFERRER field by prepending http:// because otherwise serverside tracker ignored the value. * Added BroadcastReceiver that stores the INSTALL_REFERRER parameters Google Play can provide.
… a bit clean. Downloads coming from the install source com.android.vending are now deferred by 3 seconds to wait for potential INSTALL_REFERRER information.
…t (package only).
d4rken
force-pushed
the
pr-gplayreferrer
branch
from
3c1358f
to
768827f
Compare
|
@dotsbb I'm done. adb install -i "com.android.vending" -r base.apk
adb shell am broadcast -a com.android.vending.INSTALL_REFERRER -n com.piwik.demo/org.piwik.sdk.InstallReferrerReceiver --es "referrer" "blablamyextrainfo" |
|
👍 QA and CR done, works like a charm |
|
@d4rken Please note that if campaign parameter is set, it overrides standard referrer in Piwik (so the referrer for such a visit is set to |
|
@quba Thanks for the info. Sadly this doesn't seem apply very well to the use case of tracking an app instead of a website. Our referrer is the install source, i.e. what other app installed us and for that we potentially get some extra campaign information. So to have Piwik automatically parseout campaign parameters we would have to append them to: set(QueryParams.URL_PATH, "/application/downloaded")That seems a bit dirty... It would be cool to have the campaign field somehow populated with info from the install referrer. We could attempt to parse for common campaign parameters (e.g. Piwik defaults and Google Analytics) and then prefill Or we say if a developer wants this they can extend the client themselves and add parsing or write a server plugin that parses If first dismissed the idea because I didn't like parsing for those keywords, but it doesn't seem that bad now if we elect to parse only for a few very common ones. @dotsbb Thoughts? |
|
What are the possible referrers for app download? Do you maybe have some examples? |
|
Well on the one hand the "referrer" could be seen as the app that installed our app. In case of Google Play, we actually have a second level of referrer, meaning we not only get the app that installed us (Google Play, aka com.android.vending), but also information about what took the user to the Google Play app, e.g. some link with extra parameters. |
So this is a new idea in progress:
I recently learned that the Google Play app sends an intent
com.android.vending.INSTALL_REFERRERto the app it just installed, containing the parameters that were part of it's install url e.g.https://play.google.com/store/apps/details?id=com.piwik.demo&referrer=<REFERRERPARAMTERS>.That started the whole coding session and while add it changed a few other things.
Tracker.trackAppDownload()previously passed the installer packagename via QueryParams.REFERRER without modifcation, no one seems to have noticed but Piwik backend ignores non URLs.... so we now prependhttp://Application.onCreate(), and the broadcast receiver causes it to initialize, the actual tracking is deferred by 3 seconds if Google Play is detected as download source.Contextparameter from the track download methods. Previously the idea was to use this as a way to track downloads of other apps. I've come to the conclusions though that this is not very clean because we can't guarantee certain functionality for other apps (access to the apk for checksum or receiving the install referrer). It's not something we should support, a dev could make his own method for this if wanted.ExtraIdentifier.INSTALLER_PACKAGENAMEflag. It was not a very good criteria to differentiate different downloads and this is already covered by Piwiks actual Referrer section. The default flag is nowNone.I've still got to add some unit tests and do some code polish.
For now i wanted some feedback and a question.
@dotsbb What do you think about the idea of catching the Google Play intent and passing the data along with
QueryParams.REFERRERfield? I think the idea is cool, but i fear it's too specific and a dev should decide himself if this is something he wants to add. Maybe we should not fill the REFERRER parameter at all, by default, because we can't assume this is how most of the devs would want to use it... But then again that could be argued for tracking downloads too...@mattab Can you tell me what exactly the
urlrefparameter is used for when using the HTTP API? It seems the campaign section is only filled when passing the campaign names as queryparameter or part of the mainurl. Isurlrefparsed at all? There is an extra Campaign plugin in Piwik Market, but i wasn't able to install plugins on the demo server.