Is it possible to track conversions from facebook app install ads using iTunes Analytics?
Currently Facebook strips out campaign links when setting up the advertisment. Is there any way around this?
Disclosure: I built a lot of the branch.io service, and I spent at least 18 hours a day thinking about mobile linking.
Unfortunately, since Facebook routes the user straight to their native App Store page, you can't append parameters to track page views and installs. Hopefully this will change soon, but for now, it's impossible.
If you're looking for free-to-use install and down funnel event tracking back to the Facebook install ad, we recently built out a custom integration with Facebook that allows Branch to tell you which individual user originated from a specific Facebook install ad. To do so, once you integrate with the tool, you simply need to drop a Branch link into the Deep Link field of the ad builder to start reporting on installs in realtime. We even tell you that info client side, so you can show a different custom welcome to users who come from different ads. It's not App Store page views, but you can know how many folks make it through that gauntlet overall.
I actually also just wrote a guide on how to do this if it helps:
https://dev.branch.io/recipes/advertising_facebook
Related
I am planning to use app link from FBSDK to invite using my iOS app via email.
I know if my iOS app was installed on the device it will be opened when I select the link and handle invite token in URL.
But how about if my app was not installed?
After user install it from App Store can I handle invite token also?
Hope anyone used to work with this scenario can help me.
There are a lot of reasons why what you're trying to do won't come out the way you want it to. Let's dive in...
App Links don't work anymore
Facebook created App Links in 2014 as an open standard to solve the limitations of URI scheme deep links. App Links have two main components:
A set of meta tags to add to the web page destination of a standard http:// link. These tags specify the custom URI scheme location of corresponding content inside the native app, and the behavior that should occur if the app is not installed.
A routing engine for use inside apps that support opening links. This engine checks the destination URL for App Links tags before opening it, and then launches the corresponding app or executes the specified fallback behavior.
App Links were supposed to be an open-source standard to change the world, making app-to-app deep linking simple and universal. Unfortunately Facebook has decided they actually don't want that world (it's much better for them to keep users inside the Facebook app — see Instant Articles if you don't believe me), meaning the App Links standard is essentially dead. It's no longer supported on the iOS Facebook app, and Applinks.org isn't even a separate website now.
App Links were not designed to work with email (or essentially any app except Facebook)
Even if it were still supported by Facebook, the App Links standard has a critical flaw: it requires work by both the origin and destination apps. While the meta tags component saw wide adoption, the only major implementations of the routing engine were in the core Facebook and Messenger apps.
To function as you want, where deep linking can occur from links in emails, the routing engine component would need to be implemented in any email app where your link could possibly be clicked. This was never going to happen for apps like the default iOS Mail app from Apple, or the Gmail app, for example.
App Links had no meaningful support for deferred deep linking
Deferred Deep Linking (Deep Linking refers to using a link to open your app directly to a specific piece of content, and Deferred means that it works even if the app isn't installed first) requires a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons, not the least of which being you have more important things to do. You'll notice that neither of the two App Links components included a remove server to retain link data through install, so deferred deep linking was never properly supported in the core App Links standard. Facebook ads make use of the partial support for deferred deep linking offered by the FBSDK in conjunction with App Links, but this only works when the link/ad is clicked within a Facebook app and the receiving app has the FBSDK integrated.
Deferred deep linking is tough anyway
Moving on from App Links, deferred deep linking is still complicated. URL schemes don't work, because they always fail with an error if the app isn't installed. Apple's newer Universal Links in iOS 9+ get closer in that they at least don't trigger an error if the app isn't installed, but you'd still have to handle redirecting the user from your website to the App Store. You can't pass context through to the app after install with Universal Links, so you wouldn't be able to send the user to the correct item, and they actually aren't supported in a lot of places.
Deep linking out of email on iOS is very hard
Almost all email links involve some sort of click tracking, which is always implemented as a link wrapping redirect. This isn't technically a problem if the user doesn't have your app installed, but if they do, Universal Links don't work with wrapped links. If you're building it yourself, you'll either need to completely disable click tracking in your emails, or accept that deep links won't work there.
Bottom Line
App Links were never the solution you needed. A free service like Branch.io (full disclosure: they're so awesome I work with them) or Firebase Dynamic Links is what you need. Both services support deferred deep linking, out of Facebook or almost any email app. Branch is more powerful and offers far more features, and works with major email senders to offer a solution for deep linked email (the only one on the market today).
I have installed Google Analytics SDK using the Google Analytics v3 iOS guide and I have verified that it is hitting analytics through the real time view of the analytics dashboard. I then followed all the campaign tracking v3 iOS guide, including the troubleshooting steps "Self-serve diagnosis for iOS conversion tracking." The IDFA data was getting sent to GA as verified by viewing the "Audience->Demographics->Overview" page, and all the other steps also verified we had set up the tracking correctly. I then submitted the app, waited for review, and tested the install tracking by creating the following UTM link using the google link generator at the bottom of the Campaign tracking guide (note that the link here is bogus data, but shows the general link structure):
https://click.google-analytics.com/redirect?tid=UA-1234-5&url=https%3A%2F%2Fitunes.apple.com%2Fus%2Fapp%2Fmy-app%2Fid123456789&aid=com.company.app&idfa{idfa}&cs=google&cm=cpc&ck=running%2Bshoes&anid=admob&hash=md5
I then uninstalled my app on the phone I was using to test, clicked on the link to get directed to the app store and installed my app from there. I proceeded to wait 3 days and then looked for the install in the "acquisition->sources->all" tab of analytics and did not see the campaign show up. I then looked more closely at the guide, which has the following warning:
"Note: iOS Install Tracking only works for ads served through mobile ad networks, such as AdMob that serves in-app ads."
Which seems to suggest that the only way to verify that the UTM link install gets tracked correctly is by paying an ad network to serve an add in an app and then click on that ad?? That seems absurd. So we did some backwards engineering. In Android, all one has to do is click on the link and the install gets successfully tracked. That suggested that the restrictions imposed by IDFA (an Apple innovation) made it difficult for analytics to serve a 'one link tracks all installs' solution. Looking back at the UTM link, I noted that there is an idfa{idfa} portion that presumably is supposed to include the idfa of the phone clicking on the link, which would only be possible if the app serving the add or some other entity that knows the phone's IDFA number changed the link to include that phone's IDFA. We then obtained the phone's IDFA number through the GA logs and edited the UTM link to include the IDFA number within the brackets so the portion that used to be idfa{idfa} now was idfa{}. We then clicked on that link and are now waiting for another three days to see if it shows up in GA acquisitions... We also made an Admob account and tied it into the analytics account to track the app... but it appears that is just another way to view the exact same information that is presented in the analytics dashboard.
What is the proper way to test UTM campaign tracking? Do I really have to create a mobile add, run it and click it? Should clicking on the link as generated by Google work fine and show up in GA acquisitions, and the absence of its presence signifying my UTM tracking is not working?
I am trying to track source of the App whether it is coming from Google Ads. If it is installed by clicking from Google Ads then I want to get the confirmation when a user registers.
I have followed http://mobileapptracking.com/docs/MAT-Tracking-Methods-For-Mobile-Apps.pdf but can't get any solution.
I guess, you could find the solution here: http://support.mobileapptracking.com/forums/20877789-Integrated-Publishers
It's a set of articles which describe how to add an app publisher (like Google Ads), to view the related statistics, etc.
I setup a Mobile App using the developer's panel and added all the correct information as mentioned in the tutorial video on the Facebook SDK page.
It's a native iOS app so I supplied the bundle ID and the App Store ID. I've installed the SDK and Facebook is registering installs whenever I run it on my device.
However once I tried to use the "Promote" feature to setup install ads it keeps getting rejected by Facebook on the grounds that the URL is bad. The URL works fine as I've tested it multiple times. The URL is generated by Facebook itself using the App ID.
I've tried submitting it again after changing the creative, but I'm assuming I've been blacklisted since it immediately is disapproved.
What can I do?
Is your app limited to a certain region or country?
My ad was also disapproved and this is what I got:
"The destination URL of this ad violates our Ad Guidelines or could not be reviewed. Please check the URL you have submitted to ensure that it is free of any spelling errors and that it complies with our Advertising Guidelines. Please note that all sites must be viewable and functioning properly, regardless of the viewer's location. Additionally, sites are prohibited from linking to proprietary file types (.pdf, .doc, etc,) initiating automatic downloads, or trapping a user's browser in any way (e.g., pop-ups of any kind).
"
In my case the only logical explanation would be the availability of the app, as it is only available in one country. I link directly to the app store so that should not be a problem...
Sorry for my reply, i know it's not very helpful, but there is so little info on the web about it. I need to do detective work in order to understand what is happening.
I had the exact same thing. I think Facebook changed a ton of stuff in their ads dashboard. I created a new ad yesterday and it was finally approved. Try again.
My company has an app (iOS and Android), to which the following scenarios applies. I'm trying to help point my engineers and product team in the right direction.
When one of our users clicks on a content link from one of our emails, or Tweets or Facebook posts, and they're on their mobile device, we prompt the user with a link to download our app. This is similar to what many apps do, including LinkedIn (see i.stack.imgur.com/glSgJ.png).
I imagine this is mildly effective of driving awareness and downloads of a native app, for new users who came in from social media and various web sources. However, it is not helpful at all for a user like me who already has the app!
1) clicking "No Thanks" keeps me on the mobile web (when I want to be in the native app), and
2) clicking "Download the App" takes me to iTunes App Store page for an app I already own.
SUPER ANNOYING. As a result, I have to manually open the app, and search for the content in question. I'm guessing most users don't do this. More importantly, depending on the UI/UX of the app, I may never get there!
Again, I know we are handling mobile web visits in the same way many other companies (including LinkedIn) do, but it seems we are leaving a lot of potential native app use on the table. I want our engineers to build that elusive 3rd option, "Open In App".
Spotify and Rdio have solved this very nicely. Here are deep content links (in the case of these companies, to a specific song) for the two apps respectively:
http://open.spotify.com/track/2SldBUTJSK6xz43i8DZ5r2
http://rd.io/x/QF3NK0JKWmk
If you have a moment, first grab the free version of Rdio or Spotify apps. Then, if you open those links above from an iOS device, you will see how nice the experience is, for existing native app users: Rdio has a nice "Tap to open in Rdio" link (http://i.stack.imgur.com/B7PuE.png), and Spotify's link is even more clear, "I have Spotify" (http://i.stack.imgur.com/Q3IV6.png). Both apps also include a link to download the app, for new app users. More importantly, both apps cookie the user: future visits to links (whether from email, Twitter, Facebook, etc) on mobile web automatically open the app, instead of prompting you to choose each time. SUPER CONVENIENT.
Questions:
1) How do they accomplish this? I'm initially only concerned about iOS (on which I tested this), but this same situation should apply to Android.
2) Why aren't more apps doing this? It doesn't seem like rocket science, so am I missing a key reason why this might be a bad idea? Half of my problem is convincing the use case.
3) Why don't I see discussions about this technique? I've searched a ton for an iOS solution. I come up with a lot of discussion about URL registrations (mainly app-to-app), but no one actually referring to the type of scenario I describe (mobile web prompt to open native app).
It seems that with minimal engineering, app developers could dramatically increase native app use, converting from mobile web. :)
Android supports deep linking. Please refer to
http://developer.android.com/training/app-indexing/deep-linking.html
Tapstream's deferred deep links can send users to specific views within apps (iOS only), even when the app isn't yet installed on their device.