We're running a game on Facebook with approx. 300K MAUs. However, we've noticed that there are very few credits payments.
So I looked into this and noticed that the CTRs seem really strange.
The CTR on our game payment dialog where the user can select a virtual currency package is approx. 46% (people who select a package and click on "pay").
The CTR on the FB credits dialog that opens on top of the game is only approx. 0.3%. As this is the last step in the payment process, I would have assumed this CTR is MUCH larger.
Background: The CTR on the FB credits dialog is calculated from the number of callback calls "payments_get_items" vs. "payments_status_update" with status "placed".
I am trying to figure out whether there is some implementation issue. However, I went through the implementation guide twice and did not find anything to date. All test payments have worked so far.
It would be interesting to hear about other game developers' experiences.
Thank you,
Charles McAllister
Related
We (a local hackerspace) have a Tumblr blog and wanted to make ourselves a Facebook page. Before going live we wanted to import all our Tumblr content to Facebook so our fans on Facebook can browse it here as well. For this I have made an app that reads all the posts from our Tumblr blog and publishes them to our new Facebook page (backdating those posts as well). Here's my problem: after the app does about ~130 re-posts (~260 operations: publish + backdate) I start getting an error:
Received Facebook error response of type OAuthException: It looks like you were misusing this feature by going too fast. You’ve been blocked from using it.
Learn more about blocks in the Help Center. (code 368, subcode 1390008)
The block is gone the next day, but after a similar amount of operations it's back. After a couple of hours later, when the block is gone again, I introduced 6 second delays between operations, but that didn't help and after 19 re-posts I'm blocked again. Some facts:
I am publishing posts to a feed of (yet) unpublished page I am the (only) owner of.
The app is a standalone JAVA application and uses restfb to work with Facebook.
The line that is causing the error: facebookClient.publish("me/feed", FacebookType.class, params.toArray(new Parameter[0]));
All publish operations contain a link, mostly to respective posts on out Tumblr. Some contain message, caption or a name (depending on post type).
I need to re-post ~900 posts from Tumblr, I have done ~250 so far. When over, I will likely put in on server, scheduled, to keep syncing single new posts.
This app is not meant to be used publicly, it is rather a personal utility (but the code will be posted to GitHub, should anybody need it).
This is my first experience with Facebook API and I wasn't able to find a place where I could officially address them with this question. I could proceed by doing 100 posts/day, but I'm afraid I will eventually get banned for good, even though I don't feel like doing anything wrong.
I haven't put any more code here, as the code itself does not seem to be a problem, but rather the rate at which it is executed.
So, should I proceed with 100 posts/day and hope I won't be banned, or is there another "correct" way of dealing with this?
Thanks in advance!
I'm answering a bit late but I just had this problem too so I did some research : it seems that besides the rate limits shown in Facebook docs, there's also a much more limited and opaque rate for POST requests to limit spam.
It's not clearly set but it could depend on your relationship to the page you're writing to (admin or not), if you post to multiple pages and finally if you post too quickly.
To answer the question, it seems that it would have been okay if you had done like 1 post per minute or less.
I think you exceed the rate limiting for your user Id.
- Your app can make 200 calls per hour per user in aggregate. As an
example, if your app has 100 users, this means that your app can make
20,000 calls. One user could make 19,000 of those calls and another
could make 1,000, so this isn't a per-user limit. It's a per-app
limit
- That hour is a sliding window, updated every few minutes
- If your app is rate limited, all calls for that app will be limited, not
just for a specific user
- The number of users your app has is the
average daily active users of your app, plus today's new logins
Check this: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
It looks like you were misusing this feature by going too fast. You’ve been blocked from using it.
Learn more about blocks in the Help Center.
If you think you're seeing this by mistake, please let us know.
I have an app that used to send more than 50 000 notifications weekly and dropped below 17% CTR. When Facebook blocked the app, we edited and limited the notifications to below 40 000 weekly which increased the CTR to about 20%. FB unblocked the app and DAU skyrocketed.
Today the charts look like FB blocked us again. While our CTR indeed dropped a wee below 17%, we do not exceed the 50 000 notification limit.
Is it possible that once you exceed 50 000 notifications for the first time, the 17% limit "sticks" and haunts you even if you drop below 50 000?
We just got an answer from a FB developer:
No, the limit does not stick once you've gone over 50k for the first time. If you go back down to 40k per week afterwards you should have no difficulties. We look at both click through rate and spam rate when it comes to apps that use notifications, and for more information, if your app is restricted I would recommend submitting an appeal at https://developers.facebook.com/appeal. If your app doesn't appear there, or if there is no notice of restriction on your app dashboard, that means it has not been restricted by us, and there may be something else affecting your notifications.
If you do submit an appeal I'll make sure our team takes a look and we can give you a better explanation. Make sure you keep an eye on the contact email address of your app for our response; you can find this in the Settings tab of your app dashboard if you need to update it.
For more information on notifications in general, I strongly recommend checking out our developer docs, particularly here - https://developers.facebook.com/docs/games/notifications. There's some great tips on how to optimize notifications. We allow apps to send under 50k notifications per week with no CTR requirement because we want to give developers the opportunity to test new notifications before rolling them out to wider audience. We really believe that developers can actually get much higher CTR, usually up in the mid 20's, with careful targeting and thoughtful creative work.
If you're getting that high CTR, that also means you can send notifications to a lot more people who are using your app. So not only are more people getting your notifications, but a higher percentage of people are clicking on them too.
Client looking into using QR codes in print advertising that will reward the visitor with a discount. Simplest solution (to the best of my knowledge) is to make the QR code point to a unique URL (ex. using a GET parameter for a "coupon code") that is used to store a cookie and then check for that cookie upon checkout to apply the discount.
Now most of the QR apps I've been looking at have embedded browsers. If the user scans the code and completes the purchase right within the app, I believe the above solution would work. But an ideal solution would allow the user to scan the code on the go and then visit the site up to X days later and still receive the discount. If a user returns to the site later they will probably use the mobile phone's standard browser app (i.e. Safari on iPhone) and not the app they originally used.
The answer to this question says that "each SDK app is given its own WebKit cache and cookie stores, so while cookies will persist within the same app, they aren't accessible betweeen apps." So it seems impossible to me to use the above solution to enable a user to scan a QR code and visit the site later and guarantee that a discount would be applied. I cannot think of any other solutions, but before I conclude that it simply cannot be done I wanted to see if there are any other solutions I am simply not thinking of (short of having the user create an account and store it server-side)
P.S. Obviously there are other devices besides iPhones but if I can't even get it to work for iPhones that would be enough of a deal breaker. In fact the variety of possibilities regarding mobile devices and QR apps makes me think there's a very good chance that it really can't be done.
There's no way to setup a website that will can automatically give the discount to returning visitors across different web clients on iOS. You'll need the end user's help.
You could have the QR code link to a special landing page that tells the enduser to bookmark the page to get the discount at a later date. If QR app can save a bookmark, the end user will come back through the QR app. If the QR app can not save a bookmark, the end user will view the page in Safari and bookmark it there.
You could have the end user register for the discount, and then send a discount code by e-mail. Merely asking for an e-mail address should be sufficient. When he returns to get the discount he will use the e-mail with the discount code.
The solution to this problem is not to tie discounts to browsers, but to humans. Humans tend to have the same address, and fairly often the same credit card number. These are things that are much more valuable to check than cookies. If a given billing address or credit card # has been used for a discount before, then deny the discount on the second usage. This will solve the problem 90% of the time (and nothing will beat about 90% of the time).
Cookies are a fine first step (low-hanging fruit and all that), and are fine to check if they happen to be there, but keep in mind your actual goal. You want a single discount per paying customer, not a single discount per app/device/blah-blah-blah. All the latter are proxies for the former. Focus on things that identify actual paying customers.
I am developing an application that uses FB Credits as a currency, however, my clients are going to be paying in their local currency (ILS, israeli sheqel).
I know the rate for 1 credit is 10 cents, however, the price in ILS seems to be changing according to changes in the exchange-rates of USD-ILS.
Is there a way to query Facebook Server to know the prices users are going to be charged in their local money? Like a way to query the pricelist. Many new users don't understand the concept of credits and i'd like to show them what they're about to pay in local money.
The Facebook Credits API doesn't have exchange rate information available. You could request this feature on their developer group. You're best bet would be to pull down an exchange rate feed (there are tons available if you search) and display that with a warning that it is just an estimated rate and that it is dependent on the actual exchange rate Facebook uses.
xe.com is a great feed , you can also pull data from yahoo or google finance
As stated by OffBySome, Facebook do not have exchange rate information available. Thinking about this, I can see why they don't have this as they do not want you to display the local currency price for items. Although at the moment Facebook Credits are relatively new, and there is a lot of confusion for end users, eventually when it becomes widespread there won't be these issues.
I would suggest for now (as that is what I have done - here one Facebook Credit is currently ~7p) that you just hard code in your app the price of 1 Facebook Credit in your local currency, and if required display this. I think one of the reasons why Facebook don't support this is that they didn't envisage apps using Credits to be restricted to one territory, however in reality not everything is a game to be used worldwide. :)
Just to sum this question up, I tried two methods. One was to pull the rate every 10 minutes from openexchange using this python function:
def update_ils_rate():
print "Updating ILS/USD exchange rate"
url = 'http://openexchangerates.org/latest.json'
response = requests.request('get', url)
content = response.content
data = loads(content)
return data['rates']['ILS']
However it seems that facebook credits calculates ILS(israeli sheqel) rate according to a different rate (calculations were off by a little). So we have decided to pull xml data from israel's central bank, using this function:
import requests, BeautifulSoup
def get_ils_rate():
response = requests.request('get', 'http://www.bankisrael.gov.il/currency.xml')
content = response.content
soup = BeautifulSoup(content)
currencies = soup.findAll('currency')
for c in currencies:
if c.currencycode.contents[0]=='USD':
return float(c.rate.contents[0])
I have an app that aggregates apps from the app store for a specific audience, and I use the iTunes Affiliate program (via LinkShare).
When a user taps the download button, it opens safari with the affiliate link and redirects to the AppStore. That's how I see it happening in other apps as well ("Free App Tracker", for example).
However, while LinkShare counts the clicks, I don't see any "orders", and I know there should be a few.
The clicks count gets updated the same day, while the orders count didn't get updated at all (still 0) for 3 days now.
Do I need to call the url in any specific way? or do LinkShare take their time with orders reports?
Thanks!
LinkShare track the orders in different way: there is the transaction date which is the date when the purchase was done, and then there is the "process" date which is when the transaction has been processed by the LinkShare system.
You can read more about it.
A few notes:
Are the purchases you that know happend via your link happen in the US store?
- The LinkShare program only support the US and CA programs so if the sale was made in another country you won't see any sales data.
iTunes advises that you wait three to five days for your sale to show up. I've seen sales the next day and sometimes they take longer. Typically, however, they are no later then a few days after you get the receipt for the sale.
You can call your link in a way that the redirects are processed in the background. Check out this resource for details - http://developer.apple.com/library/ios/#qa/qa1629/_index.html
Hope that helps.