I've just implemented MobFox but for the last 4 days my only response back is "No inventory for ad request". Likely it is because there is No inventory for ad request but it is very suspicious. AdMob gives me answer almost always. I'm in Czech Republic and it is posible that users in other countries will get the ads but I have no way to test it so far.
I'm using cocos2d to build an iPad app.
Could you help me out with some of these?
Is there a way force MobFox to serve test ads (I've searched for it but failed)
Is it possible that I'm doing something wrong? E.g. some setup in the account? My status for the site has turned green just after I've sent first requests. I even tried to BackFill to InMobi (pending status at this moment).
Appreciate your help --Josef
to test your ads: use a new (unactivated) publisher id
everything was fine, at this time there were no ads in CZ.
Related
I've gotten a message that my site may be knocked off of Google Merchant Center due to "Inaccurate availability (due to inconsistent availability between the landing page and checkout pages on your website)".
This affects only a small amount of products (only around 0.3% of my 40,000-ish products), so I know it's not an engine issue. After asking Google to recheck the results, they came back with the same error, but with a completely different list of products with no overlap, so I know it's not a problem on the individual product level.
There's no geo-locking on these products, and Google says that the problem exists on US IPs.
Nearly all of the errors look like this:
Value on the landing page - v:out_of_stock
Value in the data feed - v:in_stock
Performing an audit on the products in question shows that none of them have been out of stock for weeks, so the data feed is correct.
None of Google's suggested common issues (geolocking, buy button not working, product can't be shipped to an address, products not available country-wide) seem to apply. The country Google checked this on was a US-based IP.
I'm running out of ideas here, does anyone have any other suggestions?
The answer turned out to be something silly for my site, but I'm posting the answer here just in case this helps someone else.
Google's crawler was setting their country to be Andorra and attempting to check out using the US site. This is obviously not a good representation of the US experience. Google advised us that this was a mistake on their crawler's part, and that we would pass the next audit without any modifications. So if you're here looking for a solution, the absolute best advice I can give you is to find a phone number for Google Merchant Center and give them a call because the error may not be on your end at all.
Update: We passed the audit with no changes made on our part.
I'm trying to build a app that gets info from the Spotify API but since I don't have the Spotify ids I want to grab the ids using search queries.
I wanted to just try it so I tested it with an album called yellow and a band called SCANDAL. However when I query, say, https://api.spotify.com/v1/search?q=album:yellow+artist:scandal&type=album it comes up with nothing. However when I Google the band, I got an artist id: 7hTZwqQILVH4bAbN67CeEz from the URL.
using the get albums query(https://api.spotify.com/v1/artists/7hTZwqQILVH4bAbN67CeEz/albums?album_type=album&limit=5) it shows that the album exists but the original query didn't find it. Am I doing something wrong or does it only work with more popular artists (I tried other albums and it was fine)?
There doesn't seem to be anything wrong with your query. I think you are hitting a bug.
Bug reports for Spotify Web API can be found in Github issues
According to this bug:
https://github.com/spotify/web-api/issues/194
setting no market parameter will make it default to US. Your query seems to confirm this bug. Since SCANDAL Yellow is not available in the US, you will not see it in the results. If you add market=SG for instance, it will show up.
We seem to be experiencing a really strange problem when attempting to retrieve Instagram access tokens on the server side.
We're seeing "No matching code found" errors at random times, but when it does happen it seem to be clumped, as in these errors aren't spread throughout the day but only seem to be within a random 15 minute or so period late in the night, and it's only happening for a very small percentage of users during that time as we can tell.
We've looked at other possibilities, access token request IP seemed to be one possibility, however this issue is not consistent across all users in the time frame of which these "No matching code found" 400 errors are being returned during the access token request.
Has anyone experienced this before? Any ideas? Also to note, our application sees thousands of users logging in per day at any given time, so the randomness of the timing occurrence doesn't make much sense.
It looks like users get more than one code, and you see first code, but need second. Try relogin users, if you gets error. User will not see instagram page with confirm button, just redirections.
Possible algorithm of error:
1. User click auth link.
2. Get first code.
3. User click auth link (twice, redirection problem, public auth system, etc.)
4. Get another code (even on the same client_id, redirect_uri).
5. You get first code.
6. But first code already doesn't exists.
One of our users is getting an error when they attempt to make a purchase and I'm trying to identify why this is occurring.
The message returned from PayPal is:
<Errors xmlns="urn:ebay:apis:eBLBaseComponents">
<ShortMessage>Transaction refused</ShortMessage>
<LongMessage>This transaction cannot be completed because it violates the PayPal User Agreement.</LongMessage>
<ErrorCode>13122</ErrorCode>
<SeverityCode>Error</SeverityCode>
</Errors>
This product is working for other users, just not him.
Obviously it's violating the User Agreement but I'd like to identify why.
UPDATE
The users that are affected by it seem to all have one or more of the following: a non-UK email address, a non-UK PayPal account or a non-UK payment source.
We've not had a resolution yet, but have directed several users to contact PayPal directly. The feedback we've had is as follows:
"I tried with another paypal account, that failed too, despite being able to use both PayPal accounts to pay for other services."
"PayPal are aware of the error message, but they simply cannot explain why it's happening. After an hour on the phone with them today, they seem incapable of tracing the reason for this error."
Needless to say we've got some very frustrated users.
I had similar problem... Title of our item we were selling was:
Inc. Special Offer: <<Famous author>> eBook for only 10.00$
When we changed the title to something more descriptive, everything was OK
Did you open a ticket with MTS or call the Business Support line? If you did open a ticket can you please give me the ticket number? I'll take a look at it.
It may be something that you need to address with Business Support though.
I had this same error coming back for one of our customers and I had the same issue as #knagode with my product name.
For some reason "Dark Havana" in the product name set this off and produced this error. If I ever hear back from Paypal on why this phrase is not acceptable, I will circle back and edit this response.
It turns out that the value in "PaymentDetailsItem - Name" was one part of the problem. We didn't have any special characters (or so I thought) in there, just "product name: person name". When I spoke to PayPal support their response is as follows:
"I have checked it, it's a combination of many things that we cannot disclose.
However removing the ":" before the name PAYMENTREQUEST_0_NAME should work.
Can you send PAYMENTREQUEST_0_NAME=xxxx USER NAME
Instead of PAYMENTREQUEST_0_NAME=xxxx : USER NAME"
Once I had removed the ":" from that field, it started working again...bizarre!
This error still gets triggered with non-UK PayPal accounts but happens less frequently now.
For any others investigating this issue please be aware that PayPal has filters in place that looks for globally specific geographic terms. If any terms used in the product description trigger the filters, the transaction could be refused. In our case, we are online rug retailer with many of our products ranging across the traditional rug spectrum. We found that any rug with the term "Persia" in the title were being refused due to economic sanctions against nation states associated with that term.
The filters are not geographic only and other controversial terms could also trigger the filters to refuse the transaction. In one instance, we had a rug with "Confederate" in the product description that also triggered the filters.
I'm tring to search locations with the Instagram API in my application but also when testing with Apigee, I get 500 Internal server error, and Oops, an error occurred.
Apigee: https://apigee.com/console/instagram
Authenticate yourself and add this URL: https://api.instagram.com/v1/locations/search?lat=40.758896&lng=-73.985131
It should return Time Square locations. It worked a few times in the past, but currently it doesn't.
It would be an overkill to use the Foursquare api to search for locations, then pass the location id to Instagram. Is that the only way to get around this? Because once you know the location's ID it works ok.
My possible solution would be to let the user find the desired location here: http://worldc.am/id/47383924f964a520444c1fe3
And use the v2 foursquare API location ID for Instagram.
The Instagram API is pretty bad in that regards - it often just says "Oops an error occured!", without giving you any more info.
I believe their servers have a really low time out limit. Add the parameter distance=500, or even less, and you won't get this error any more. Basically, in a high density area (like a big city), you need to specify a small distance number, otherwise Instagram's server just times out while serving your request.