Categories
Uncategorized

API Changes

Some upcoming changes at Auction Request that may impact you:

eBay will be discontinuing their old API on Dec 31st, which Auction Request has been utilizing. We've finished converting our code to the new API, which has necessitated some workarounds for features that are no longer available. While we were able to overcome most of the incompatibilities, a few remain:

  • If you have a feed that searches a seller name only (with no keywords or categories), you will need to add a category to this search. While you can use the AR feed generator for this, you can also add "&categoryId1=" and a category number to your existing feed URLs. This is annoying, but thankfully most sellers' items will be covered within a single "root" category. If needed, you can add up to three separate categories to cover a wide spectrum of items.
  • the filter for TopRatedSellersOnly has been removed. If present in your feed, it will now do nothing.
  • the filter for "Buy It Now" auctions has been removed. There are now only three choices here: Auction, Fixed Price, or Everything. If present in your feed, it will now revert to Fixed Price.
  • the filter for items that accept PayPal has been removed (as PayPal is no longer part of eBay, and they're trying to get rid of the payment option entirely). It has been replaced by the "Credit Card" payment filter, which we do NOT recommend you use as very few items on eBay are payable with credit card.
  • the sorting option of "Most Watched" is still present, but it may not work correctly. In test searches we've run, no data has been returned that show a Watch count. This could be because the feature is broken, or that nobody actually uses the Watch function on eBay anymore.

So that's all the bad news. Some good news:

  • Feeds will now return up to 400 items (increased from 100)
  • Priority Listings (those items eligible for 50% higher commissions payable to you) will be displayed at the top of your results regardless of your sort choice. Within this group of Priority Listings, they will be sorted only if you selected as your sort option Highest Prices First, Lowest Prices First, or Most Watched (eBay does not return start & end times to us on most items now). Non-Priority listings will be listed after the Priority Listings, and will sort according to your choice (the option to sort via start & end times works for these listings, since eBay is doing it on their side). It's complicated and confusing, but the takeaway here is that Priority Listings will always be at the top, giving you an optimal chance to make a higher commission. With that said, only certain ePN members are eligible for this higher Priority Listings commission, though who is eligible is not made clear. 🙁

The new code will go active on Friday, December 31st, and the transition should be seamless (fingers crossed). If you experience any unusual behavior, please let us know immediately. The old code should work for a month or two longer, so we can swap it back in if problems are encountered.

Thank you for your continued support and patronage!

Categories
Uncategorized

Fix for Facebook posting

We've implemented a fix for the Facebook issue identified in this eBay Partner Network post: https://partnerhelp.ebay.com/helpcenter/s/article/Mobile-Deep-Linking?language=en_US#facebook_app . It involves correcting attribution when a user opens an ePN rover link from with the Facebook app. Note that the fix only affects the iOS app; there is no fix at this time for the Android app.

Categories
Uncategorized

Corrected issue with non-US clicks

…and apparently I didn't have it quite right. Non eBay.com clicks (to www.ebay.de, for instance) needed to have the siteID parameter correctly coded. That has been fixed now, so all clicks as of 18:30 GMT this Saturday should now be tracking.

Apologies for that. 🙁 The siteID parameter was an undocumented feature of the new links, which I only picked up on by playing around with the SmartShare browser extension.

Scott

Categories
Uncategorized

ePN Changing Affiliate Links

ePN just notified everyone (you should have received an e-mail from them today) that as of March 31st, the rover link format is changing.  I updated the Auction Request rover links to this new format just now; please advise immediately (in reality, tomorrow morning / Saturday morning when your ePN earning stats will reflect the new link structure) if your rover links do not appear to be working correctly.  I think they'll be fine, but who really knows at this point.

The old link structure looked like this: 

https://rover.ebay.com/rover/1/711-53200-19255-0/1?mpre=https%3A%2F%2Fwww.ebay.de%2Fitm%2F184659519294&campid=0123456789&toolid=10001

The new link structure looks like this: 

https://www.ebay.de/itm/184659519294?mkrid=711-53200-19255-0&siteid=0&mkcid=1&campid=0123456789&toolid=10001&mkevt=1

Note that for eBay domains outside the US, the new links will correctly go to that eBay domain (www.ebay.de, for instance) where the old rover links were always rover.ebay.com.

Why did ePN do this?  I do not believe it has anything to do with Auction Request specifically, as this would have had to have been in the planning stages for some time.  Publicly they're saying it's to bring the rover links up to "industry standards", which is software-speak for "the real reason is something else but everybody likes to hear about industry standards".  In this case, the new structure avoids a redirect on eBay's side, which was probably the main reason for the change.  The second reason for the change was to purposely break all third-party tools and scripts, many of which are old / will not be updated, so they'll get to pay out less affiliate commissions.  Just my wild guesses here of course.  :/

Lastly, the new (hidden) front page for all subscribed users is here: https://www.auctionrequest.com/welcome-to-auction-request-2/

Scott

Categories
Uncategorized

Auction Request Going Dark

Due to two users who felt the need to publicly post that ePN had told them to stop using Auction Request, we expect ePN to make the public announcement that Auction Request (and any other third-party feed) is no longer allowed. To date, we still have not been contacted directly by eBay, and the only indications that we are running afoul of their terms is via three users who were audited by ePN in recent weeks:

— The first user never contacted us; he cancelled his Auction Request account and then posted on the ePN forum that Auction Request was now banned.

— The second user did contact us, and we told him that removal of link cloaking (rover links going to auctionrequest.com instead of rover.ebay.com) may have been the root of the problem. He told ePN that his links had been changed to remove Auction Request (which was the truth), and they were apparently fine with that; his usage of us continues.

— The third user contacted us and said he told ePN he was using Auction Request, and ePN repeated the boilerplate response that Auction Request is not allowed. We advised him to discontinue using us, and to re-enable his feeds after a month or two. He did not respond, and instead decided to post on the ePN forum, which will now force ePN to declare a public policy on the matter.

Our guess is that the central issue in all this was the link cloaking, which has been discussed at length. But "Auction Request" is a bad word at ePN right now, and it's a lot easier to just declare that we're "banned" rather than work with us on a solution that benefits everybody.

Therefore, in light of all this, we took a few steps today:

— The Auction Request home page now just displays a message that the service has been discontinued

— No new users will be accepted

— Our service, for the meantime, will continue. This obviously is subject to change at any time. If we do decide to shut down completely, all yearly subscriptions will be refunded at a pro-rated amount of time left

— As a current subscribed user, you can access a new (hidden) front page: https://www.auctionrequest.com/welcome-to-auction-request-2/

Moving forward, this is the deal:

— Yes, this is scary, and if you want out, we'll refund any yearly subscription with a pro-rated amount at your request, no questions asked. Whether monthly or yearly, it's best to cancel your subscription yourself within PayPal for this.

If you receive income from ePN that is separate from the RSS feeds, you will need to weigh the risk of continuing with us versus cancelling and thus salvaging your other income streams. If Auction Request represents the entirety of your ePN income, you really have nothing to lose by continuing; whether Auction Request is shut down or your ePN account is terminated, the end result will be the same. Do not count on getting a warning from ePN that you need to stop using Auction Request, as the previous three users did. Since we assume it will shortly be a public policy, they can and will terminate you immediately if they suspect you're in violation. ePN is somewhat famous for such heavyhandedness.

— With that said, we do not believe eBay is able to detect that you're using Auction Request to get your feeds (unless you tell them!), as your rover links now look identical to the ePN Link Generator ones. Indeed, the 2nd user mentioned above is proof-positive that ePN is oblivious that he did not stop using us.

If you post anything regarding Auction Request on the ePN forum, your account with us will be terminated. Zero tolerance policy on this. In order for our service to continue, eBay cannot suspect that we're still serving feeds, or they will come after us with legal action.

— If/when you are audited by ePN (they do this periodically on everyone, so it eventually will happen), avoid any mention of Auction Request. One of the standard questions they ask is "describe how you generate traffic for eBay". You're manually posting auctions and you obtained your rover links via the ePN Link Generator tool. If you state you are using Auction Request, your ePN account will be terminated by eBay, possibly now with no warning.

As an aside, ePN never originally approved the Auction Request business model; we didn't approach ePN. There was absolutely zero chance that they would permit a service to replicate the RSS feeds that they were in the process of shutting down. While they certainly were aware we existed – we advertised on the ePN forum! – the higher-ups most likely took a blind eye, because the actual impact to their servers continues to be negligible, and we're also keeping several hundred ePN afffiliate users in the program (which benefits everyone). While we can argue the merits of this, the point is that eBay – and ePN – have been on a very public crusade to slowly chip away at their own business model and userbase for years now, with head-scratching business decisions and reductions/eliminations of affiliate commissions. Auction Request was an attempt to salvage the affiliate program for hundreds of users from eBay's own idiocy. Their idiocy may have caught up to us.

If you have any questions, concerns, or just want to vent, please reach us at [email protected]. If you decide to cancel your service, we thank you for your support these past few months. If you decide to continue, we wish all of us the best of luck in surviving this.

Regards,

Scott & Rhys

Categories
Uncategorized

Removal of Free Tier & Link Cloaking at Auction Request

Today, we've made the very difficult decision to remove the free tier of Auction Request, as well as disable link cloaking and geotargeting for Premium users. Whilst not a decision we wanted to take, it's unfortunately necessary in order to preserve the integrity of the services we offer.

The Free Tier Explained

Up to this point, we've allowed free users to use Auction Request to list their auctions, but in return we would add our affiliate code to the links. The income from this, while relatively small, justified the server resources allocated to it, and also served as an extended "free trial" of Auction Request. In order to prevent free users from changing our ePN campaign ID to theirs, we routed their links through Auction Request's servers. So a link to auctionrequest.com/ap.php?uid=sampleuser&itemid=1234567890, for example, would arrive at our server, we'd compose the appropriate eBay rover URL, and then append our campaign ID to it. The click would then be forwarded to eBay to view the item in question. Technically speaking, this was accomplished via a 301 server redirect, so eBay should have (correctly) seen that the click was made from sampleuser's website.

What Happened?

A couple of weeks ago, we were contacted by ePN to state they wanted to investigate how we were generating traffic. We explained the situation to them, and provided the data they requested — the websites using our free tier. Unfortunately, a few days ago they responded to say that they believed Auction Request was generating "non bona-fide transactions" and that our ePN account was immediately terminated. While we did no such thing, we were not allowed any chance to fix it, nor did ePN provide us any specifics on what they saw as "non bona-fide". All of our free-tier clicks? Just some of them? Did this just start? Etc.

So, without knowing anything more about what the central issue is, we've come to the conclusion it must be one of two things: 1) routing clicks through our server, even with a 301 redirect, is either obscuring the source of the click to eBay, or introduces the possibility that we might be illegally generating false clicks. 2) One of our users is generating false clicks, which when routed through Auction Request's server and our campaign ID attached, becomes Auction Request's problem.

Again, without knowing specifics on what eBay has an issue with, or giving us a chance to fix it, we're left to conclude that we cannot process clicks through our server. Therefore, effective yesterday, all link cloaking (and the associated ability to geotrack) has been disabled. Premium users will see their rover links pointing straight to eBay (many of you may already be doing this, so you won't see any change). The links will not geotrack, as ePN does not natively support this ability. Additionally, displaying affiliate links on your website runs the risk of the "Google hammer"; your mileage may vary. While this all sucks (to put it bluntly), we don't want to risk any clients being targeted by ePN for suspicion of "non bona-fide transactions".

As far as the Free tier goes, without any income from our campaign ID attached to those links, we unfortunately can't justify providing server resources for feeds that nobody's making any affiliate income off of. Combined with the inability to prevent free users from adding their own campaign ID and circumventing our subscription plan, this makes the Free tier unviable going forward.

Summary of Changes

  • We have switched off the Free tier – Emails are going out shortly to all free users encouraging them to switch to a Premium tier. They'll get the standard 14-day free trial to see how it works for them. The free tier is now no more, unless ePN allows us to restart it.
  • Removal of Link Cloaking and Geotargeting – We suspect link cloaking was the problem. We've switched off link cloaking so all rover links now go directly to eBay. We invite representatives from eBay to review our code to see that what we were doing was above board, but if past experience is any indication, they are unlikely to take us up on this.
  • Raised Prices – With the double-whammy of the loss of affiliate income, plus the costs of the new dedicated server we obtained last month, we're unfortunately forced to raise subscription rates in order to keep the lights on. If you are currently on a Premium tier subscription your rate will remain the same, but all new subscriptions or upgrades will be at the rate of $12/month or $120/year. The new rates will go into effect in two weeks, on February 7, in order to allow current Free tier members to subscribe under the old rates.

As always, please contact us directly for any questions you may have.

Categories
Uncategorized

Auction Request Downtime: What We've Done to Make Sure it Doesn't Happen Again

As a follow-up to our recent blog post regarding steps we've considered to avoid the downtimes & outages we've experienced, I'd like to update you on where we currently stand.

This past weekend, we switched the Auction Request service over to a new dedicated server. This server is faster than the old one, and has additional resources to manage increased load. While the load on the old server did not cause any of our outages, we felt it was a good investment to make now, with an eye towards future expansion.

This past month, several of our high-throughput clients were being mysteriously blocked from accessing our service. While this took us a number of weeks to diagnose, we did eventually discover that our old server's hosting company was behind the blocks, as they saw the high-throughput API requests as a DoS (Denial of Service) attack. In order to mitigate this, we're now incorporating Cloudflare's proxy service. It's important to note that Cloudflare does not enable us to survive a server outage at our host; since we provide an API service that interfaces with eBay, not a static website, viewing a cached copy of Auction Request doesn't work. Cloudflare does enable us to engage their more sophisticated firewall to survive outside attacks, as well as a DNS failover service that can instantly redirect auctionrequest.com to another IP address should our current IP address not resolve.

What this means in layman's terms: we're going to utilize our old server as a backup server. Should Cloudflare detect that our current (new) server has gone down, they will automatically switch the service over to the backup. Theoretically, this will occur relatively quickly (within a few minutes or less), and again theoretically, should largely eliminate any further downtime. The odds of both servers being down at the same moment is mathematically pretty low.

The backup-redirection mechanics have not been enabled yet, but will be in the coming week, once we're satisfied that the new server setup is performing optimally.

We thank you all for your continued patience as we overcome these technical challenges. Your business is very important to us, and we continue to make investments to provide the fast, reliable, professional product you deserve.

Categories
Uncategorized

WP eBay Product Feeds – Extra Spam Checker launched!

Since one of us here at Auction Request also created WP eBay Product Feeds, it makes sense that the plugin and this site do tend to work well with each other. It's this cooperation that has lead to a new tool – our WP eBay Product Feeds – Extra Spam Checker helper plugin.

This plugin, designed for WordPress, improves the spambot checking that currently exists inside WP eBay Product Feeds. It pings external servers to check if the traffic is a bot, and if it is, your listings are hidden. (It has to be in a separate plugin, rather than embedded into WP eBay Product Feeds, as WordPress.org's repository doesn't allow pinging external sources).

We've been testing this plugin with some of our heavier users who use WP eBay Product Feeds, and it seems to work well, so we're offering it up to everybody now.

Visit the WP eBay Product Feeds – Extra Spam Checker page on this site for more details, instructions on how to use the plugin, and how you can help us, or alternatively please click this button to download the plugin.

Categories
Uncategorized

Auction Request Downtime: What Happened & What We Will Do To Make Sure it Doesn't Happen Again

Hi Everybody,

As you are no doubt aware, we had some quite significant downtime this week. This blog post will hopefully explain the situation and what we'll do to mitigate these issues in the future.

What Happened?

On 7th September, roughly 7pm UK time, our host provider (Hostinger) began noticing a problem with the US datacenter that Auction Request is located on. We had a hardware component failure.

This resulted in the site going down and everything associated with it (everything is hosted through there, so we lost email & pings were resulting in the server hanging). After speaking with Scott (which in itself was tricky due to a lack of email not hosted via Auction Request), we found out – unfortunately – at the time – there was very little we could do, with no real way of communicating with users via official channels.

We resorted to unofficial channels where we hoped to reach a large proportion of our customers, to spread the message and to and manage expectations. I sent out a message to users of my plugin – WP eBay Product Feeds (including emailing all known active customers), and Scott put messages on a PHPBay Facebook support group.

What Are We Doing to Prevent This from Happening Again?

Obviously, we don't like this happening. In my (10+) years of working on web development systems, I believe I've only experienced one or twice this amount of downtime. Although there's very little we can do in terms of the actual downtime (we were unfortunate that our server was hit), we're looking to obviously mitigate the issue so it doesn't affect us to this extent again .

This is what we're doing:-

  • A number of off site support channels are being set up – We're first off setting up a Twitter – it's available at @AuctionRequest, as it's probably the easiest thing we can do. Whilst we'd prefer not to be using this during normal operations for support (please, contact us if you need to do this), it'll help us get the message out when there's a service disruption.
  • Decoupling of emails from the site – Obviously, having both emails and the website hosted in the same place is not great. We're looking into ways in which we can use third parties to host emails.
  • Reviewing where our DNS is hosted – we're going to take a look at a few things, linked to the decoupling of the emails. One such thing is decoupling the DNS from our main host, with a service like Cloudflare. This will allow us to restore things a bit quicker if we have a similar event (I feel I should reiterate that although we suffered downtime, no data was lost, and we take daily backups).
  • A comprehensive hosting review – Due to the original rush in getting the site live, we probably didn't spend as long as we would have liked in reviewing hosting options. Now that things are back to normal, we'll be spending some time reviewing our options moving forward.

Again, we're really sorry with what happened. I know how hard both me & Scott have been working on this project, and having this happen outside our control is frustrating. I hope that our level of support has helped shown support in what we're trying to do.  

We're happy to take questions over email, and we'll update this post as needed.

Take Care

Rhys Wynne

Categories
Uncategorized

API Call Usage & Statistics

As we've now been "live" for about 50 days now, with a sizeable user base that's provided much better real-world usage than we were able to simulate in testing, we've implemented a number of things in order to regulate how the service is used.

This article may get slightly technical, so a brief summary before we start: if your API call usage gets too high, you'll receive an e-mail warning to that effect.  An increase much beyond that level of usage will result in another e-mail, and the system will temporarily block you.  We'll also be notified, and will work with you to figure out the reason for the high usage.  To date, we've had a handful of users who've hit the "warning" threshold, but in each case, we were able to bring them down to "safe" levels without too much trouble.

For Premium users, you can view your recent API call usage and click-thru statistics via the "Your Stats" page, off the main menu.

So now the more technical parts:

The true "load" on the system is actually not how many calls we're sending and receiving to the eBay API, but how much RAM and CPU resources are consumed on our server to process a single call from a user.  This was a bit of a surprise to us, and necessitated some extensive code optimization in order to minimize disk access and server database queries.  We're comfortable with the limits we have in place now, the server load has calmed down, and thankfully we've been able to assist the (very few) users who had overly high throughput.  We're also very happy with the performance of the WP eBay Product Feeds plugin, but users who have either modified the plugin, are using a different CMS solution, or most importantly, are utilizing a feature where an end-user can search eBay through our service (which ends up getting exploited by bots), have in some cases been causing issues.  As mentioned, should this occur, we'll work diligently with you to examine your usage case and hopefully implement some code additions on your side to help mitigate and get you below that critical threshold.

When viewing your Stats screen, some things to keep in mind.  Because we have a cache system in place (a 5-minute cache for Premium users, and a 30-minute cache for free users), identical calls received by our system within that cache window will be served the cache result stored here, without needing to query the eBay API.  Any of these "cache hits" don't count towards your API call usage.  Additionally, most error messages you get were caught by us before querying eBay, and they won't count either.  Lastly, we have bot-filtering algorithms in place to cut down on the number of search-engine bots, or crawlers, that are viewing your feeds and causing API calls.  All of these strategies have dramatically reduced the actual API calls you're making, and may be quite a bit less than what you would expect.

(Incidentally, this experience in monitoring usage real-time has revealed what I believe is the primary reason eBay shut down the RSS service.  Without any ability to filter bots, regulate usage, or serve a cache, their RSS would have been hammered by literally tens of millions of queries per day.  The resources to handle that would have been quite formidable, and costly.)

The usage metric we're looking at is your calls to the API over the last thirty-minute period.  We check this every five minutes, in order to better catch a sudden massive spike.  The API call stats you see on your Stats screen will be five minutes or less "behind live", so if you make an API call and then run over to check the stats screen, it may take up to five minutes to reflect.  The click stats are live.  The click stats also require you to have enabled Link Cloaking in your Profile, as that's the only way we're able to track your clicks.