This is getting frustrating. Emailed RevMob and pointed them to this thread but they’re not responding at all. We’re stuck and we can’t update our apps because doing so may just affect our ad revenues.
Hi Egarayblas:
I suggest you upload your app with new update first ( Make sure use new sdk with IDFA support ).
Anyway , I think this month is better then last month .
Hi RevMob & fellow developers,
As a UK developer I integrated a “Free Game” button into my app. When I downloaded my app to my own device and touched the “Free Game” button I got this:
It’s rather worrying as this appears to me to be potentially lost revenue…
That might has well been a 404.
My app is growing installs now that it’s got a little bit of traffic on the store. About 1 installs per 150 clicks.
I think somebody already guessed that the iPhone 5 running the latest os don’t post installs. Seeming that’s probably 60% of that active market to us. But only 5% of revenue to revmob. This is a huge loss to the developer of actual rev.
It’s up to Revmob to fix or better force the advertiser to use the latest s2s protocols and stop being so damn careless with our livelihood.
I’m starting to see some installs now. Not quite as many as I used to, but more than zero (which is what I’ve been getting over the past weeks). Using Corona 1127 and Revmob 5.2.1.
Could you clarify the iphone 5 comment. Is this something revmob is aware off?
I think I have this figured out (with a little experimentation of course).
RevMob is in the middle of a transition right now. They have tons of apps from pre-May 1st. These apps report UDID but not IDFA. The rest (newer ones) report IDFA.
The app RevMob is advertising within YOUR app must use the same identifier (UDID or IDFA) in order for you to receive credit on the install. If YOUR app is UDID and the advertised app is IDFA, or vice versa, RevMob will not get credit for the install because they cannot confirm it, and neither will you. It’s pretty much giving away a freebie.
There’s nothing RevMob can do to 100% fix this situation right now, but iOS 7 does not transmit UDID or Mac Address, EVEN if the app is compiled for iOS 6 and below. So in the fall ALL apps will have to transition in order to use RevMob.
In the meantime, the best fix I could see is RevMob could stop delivering ads based on the RevMob SDK version. If the SDK version is too low, you won’t advertise IDFA apps, if the SDK version is new, you won’t advertise UDID apps.
Anyway, we’ll probably just have to tough it out until iOS 7 releases. (And I doubt we’ll ever get credit for iOS 5 installs ever again)
Great post Puzzle Runner. I’ve been thinking along similar lines myself, though I never did the experiments that you did to try to prove it out.
I’m thinking that this is only really a problem for advertised apps that are still using UDID, i.e., that haven’t released an App Store update since the UDID ban went into effect. When a user clicks an ad for such a “grandfathered” app, and the app gets installed, the app will report to RevMob the installation based on UDID. RevMob won’t be able to correlate that install with the app that displayed the ad, which will have reported the click based on IDFA or the MAC address.
But, for advertised apps that aren’t using UDID, i.e., that were released or updated since the UDID ban started, when a user clicks on an ad for it and installs it, it’ll report to RevMob the installation based on IDFA for iOS 6 or MAC address for iOS 5. That should correlate with what the app that displayed the ad reported, so the install should be trackable.
In any case, other CPA ad networks are going to face similar challenges, not just RevMob.
I’ve also thought about the possibility, but I haven’t tested it, that the MAC address hashing isn’t working, in which case no iOS 5 installs would be trackable. When Corona provides the MAC address via system.getInfo(“deviceID”) (which is what the RevMob SDK uses on iOS 5), it applies the MD5 hash. I don’t know whether it’s applied directly to the raw bytes or to a string representation of the address (with colons). If it happens to be done one way in that API, but the native RevMob iOS SDK does it a different way, then the hashes won’t match, and no iOS 5 installs would be tracked. Again, I haven’t tested this, it was just another way I could potentially see install tracking failing to work.
- Andrew
P.S.: I’ve just tested and found that system.getInfo(“deviceID”) hashes the MAC address in string form, using capital letters, without any colon or dash separator. I’m not able to tell what the native RevMob iOS SDK does, but according to the changelog (http://sdk.revmob.com/ios_download.html), they only started “encrypting” (hashing) the address a few weeks ago, on 22-May. Either way, it’s quite possible that they format the address differently, or use the raw bytes, before hashing, in which case they’ll get a different result.
I have do some test on RevMob and some CPI base ads providers .
Regarding iOS5 . they all have the same problem . They can not trace correctly .
Because iOS5 do not support IDFA . But now App should use IDFA only.
Good ads provider should not send ads to iOS5 device .
iOS6 have a little confuse . Because it support both UDID and IDFA . so , it would be have some missing data. especially in Corona SDK . because Corona support IDFA almost in the end of May. Developer is hard to support UDID and IDFA both .
If it support IDFA before replace UDID for hash MAC. I think RevMob can record to mapping IDFA and UDID .
So , that’s why it seem only happen data missing on Corona SDK .
in iOS7 , I do not do any testing .