Please make sure you get v1.22 if you have not already (use download link on left). I made a “small” ommission in v1.21 which meant that Sign up and “Search eBay” links were not forwarding properly (well, not at all in fact). This is fixed now.
Sorry these updates are so haphazard - it’s what happens when I only have one day to work on WordBay and I try to rush things. Hope you will now be up and running, with all the recent bugs ironed out and a couple of little new features. But if you see anything untoward happening I just know you will let me know!
There was an odd little quirk where links were appearing that were in the format cgi.ebay.com and not the rover.ebay… affiliate link type. This would happen if a campaign ID had not been specified - the feed API would return non-affiliate, “cgi” links, as was the case with the user who complained of this. But I managed to reproduce the problem too a couple of times and can’t work out why, since the site I tested on DOES have the campaign ID specified. Right now I am still at little jumpy because of the click tracking problems some people were reporting and that eBay partly admitted to, so I would like to keep an eye on that. If you see links on your product listings forwarding to a short link like http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=370325891590 instead of the longer http://rover.ebay.com/rover/1/711-53200-19255-0/1?… etc. then let me and other users know as it could be important!
Posted on February 24th, 2010 by markowe
Filed under: Uncategorized
P.S. Oh, with all these updates and little bugs being found, I decided to add a “Feed subscribe” box in the admin backend. To the best of my knowledge only a very tiny proportion of WordBay users keep their plugin up to date and/or follow the blog, so it would be good to have people sign up to be updated (just with posts from the blog) so they know what is going on, and don’t miss critical updates.
About the cgi.ebay.com vs. rover.ebay.com links.
I’m seeing my links going from:
http://www.sitename.com/wp-content/plugins/wordbay/buy.php?buyurl=xxxx___xxxx
to
http://rover.ebay.com/rover/1/710-53481-19255
-0/1?icep_ff3=2&toolid=10005&campid=xxxx&cus
tomid=http%3A%2F%2Fwww.xxxx.com%2Fxxx&ice
p_item=xxxx&ipn=psmain&icep_vectorid=23843
1&kwid=902099&mtid=824&kw=rss
which in turn goes to:
http://rover.ebay.co.uk/rover/xxxx
Which finally goes to:
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?xxxx
So while we end up at a .cgi.ebay page, the click does look like it is being tracked on its way through.
(you can do this trace with a Firefox plugin called Live HTTP Headers or by using this site)
Mark,
I addressed this issue on the v1.21 post, but decided to move it here since this is the version I am dealing with.
I updated my Wordbay plugin to the newest version (v1.22) from the WP admin area. It appears that everything looks right on my pages but the links are going to a 404 (Nothing Found) error page on my site. My buy.php is called shop.php on my site. I am wondering if this could be the problem.
Here is one page on my site where this is occurring. Please delete this link from my comment if necessary.
http://makeavideo.net/samsung-digital-camcorders/
I know that a few others have been having the same issue. Has anyone found a solution yet?
Thanks.
First of all thanks for doing all these updates Mark.
While these new fancy addons are neat, I feel like the main problem - the correct tracking of urls by EPN - is still not resolved. As a matter of fact, my clicks have taken a further dump when I upgraded to the 1.21 release about 4 days ago. It is my bet that this can be explained with the cgi.ebay forwarding instead of rover.ebay.com. Thats definitely occurring with me and it doesnt matter where I click on (title, “click for details”, “buy now” etc.). Whats going on here?
The strange thing is that when I uninstall this WordBay version and delete it and now try to install an older version (From 2009) it still takes me to cgi.ebay!? So if you ask me, we’re getting to the bottom now where the conflict is between EPN’s updates and WordBay!
Its possible that EPN just doesn’t want their affiliates to use these types of 3rd party softwares anymore - though if thats the case they should flat out tell us instead of doing these behind the back tweaks. May I suggest that you contact EPN directly Mark and ask them kindly to look into any potential EPN tracking problems aka update incompatibilities with WordBay? I will contact them too but Im sure it will help if the author himself brings this to their attention. If other WordBay users could ask EPN for any reporting discrepancies, that would be great too. Because its very possible that EPN has made some changes unbeknownst to us that dont process plugins like WordBay correctly anymore. At least in the state it is in right now. We need to get this fixed! Who know, we may even be forced to switch to EPNs own feed options in the end - though I would like to remain optimistic.
PS: I always made sure to have my campaign ID set so this cannot account for the cgi.ebay forwarding.
Update: I just did some base 64 decoding of the WordBay links and there they show as rover.ebay links. However when I click on them on my website it takes me straight to cgi.ebay links, even in the loading bar. Is this normal? I dont remember this from before as I never really paid attention to this. When I click on my custom affiliate links (non-wordbay) the rover.ebay does show for a while during loading, until it gets to the final destination (shop.ebay or cgi.ebay). So it still appears that something fishy is going on.
On further inspection I uncovered something interesting and to me confirms the fishiness. Ok, here’s an example of a decoded WordBay link from my website:
http://rover.ebay.com/rover/1/707-53477-19255-0/1?icep_ff3=2&toolid=10005&campid=xxxxxxxx&customid=mydomain.com&icep_item=190375843455&ipn=psmain&icep_vectorid=238641&kwid=902099&mtid=824&kw=rss
And here’s the link when I generate it via EPN via item ID:
http://rover.ebay.com/rover/1/711-53200-19255-0/1?icep_ff3=2&pub=5574794143&toolid=10001&campid=xxxxxxxxx&customid=mydomain.com&icep_item=190375843455&ipn=psmain&icep_vectorid=229466&kwid=902099&mtid=824&kw=lg
Now, I realize that the latter is not generated from the RSS so I assume that this makes for the difference in the vectorid at the end? I also see some differences in the beginning though that I think shouldn’t be there. E.g. 711-53200 instead of 707-53477. The latter also has an additional pub ID. Could these different numbers cause any tracking problem from WordBay? No matter what generation option I use in the EPN interface, these numbers always come up as 711-53200 while the WordBay link shows 707-53477. Im no expert on these matters but I figure it cant hurt to bring this to attention.
Either way I just send a long email to EPN support, hopefully they will look into any possible tracking issues. Again, I think it would great if you contacted them too Mark.
OK, something is definitely going on here. Thanks again for your input Dennis, I hope your persistence pays off in the end! I am going to look into this as soon as possible and try to find a definite fix in the next couple of days, so stay tuned.
Pat, re: your issue, it almost certainly IS because of you changing the name of the buy.php to shop.php, IF it was located in the plugins/wordbay directory. I never introduced a way for this file name to be preserved. To be honest I never thought about it, I always assumed people would locate buy/shop/store/foobar.php in their root directory or something.
So all you have to do is rename buy.php to shop.php and you should be ready to roll. I HOPE. This is another of those quirks I can’t believe never came up before….
Dennis: I’ll bet you have geo-targetting turned on?
707-53477 is the geo code for Germany while 711-53200 is the code for the US, but both links point to the same item.
WHOIS on your domain puts you in Germany, so if you are viewing your wordbay site from your hometown you would get German geo code.
I also checked every wordbay link on your front page using the tools I listed at the end of my first post. All of them go to rover…then onto cgi. I tested all three buy links (image, title and “buy it now” text)
All in all I’m not seeing anything wrong (but will be happy to be proven wrong)
ChuckMcB, thanks, that pretty much echoes what I wrote to Dennis in a private correspondence. I admire Dennis’ persistence, I really do, but I am still stuck for some definite proof that clicks are going missing. I have done a little test to see if some clicks of mine will get tracked, but that will take a day or so to come up, and anyway, clicking on your own links is neither reliable nor recommended… I also tested lots of RSS links and got no dodgy results…
Yes, re: accessing WordBay directly, can’t be done
In techno-speak, WordBay plugins are effectively classes, which have to be instantiated and accessed from within Wordpress. So that means no…
>>Dennis: I’ll bet you have geo-targetting turned on?
707-53477 is the geo code for Germany while 711-53200 is the code for the US, but both links point to the same item.
WHOIS on your domain puts you in Germany, so if you are viewing your wordbay site from your hometown you would get German geo code.<>I also checked every wordbay link on your front page using the tools I listed at the end of my first post. All of them go to rover…then onto cgi. I tested all three buy links (image, title and “buy it now” text)
All in all I’m not seeing anything wrong (but will be happy to be proven wrong)<<
Well, all I know is that Ive been missing about a 1/3 of my clicks (and hence earnings) since February 11. Im very sure about this. (Though I remain open minded that my click inflation is some sort of 2nd half of February fluke, despite my immense organic traffic jump for the same period) If the problem is not from WordBay per se, then I’m inclined to say that the problem is due to geo-targeting tracking on EPNs end. As we know there were errors reported regarding UK (& other country) tracking after Feb 11 and EPN has been very vague about that, only mentioning some sort of “mapping error” and that a makegood will be issued. From what I can see the problem is still going on though, at least in my case.
It is very frustrating to see this stuff going without being able to nail it down (hence my “persistence). If EPN was more transparent half the battle would already be won. I got a response from them yesterday that was totally ignorant of what I had outlined in detail in my email, only suggesting I should use the tool validator. Well, thats totally pointless as that tool doesnt “see” the WordBay generated affiliate links and hence doesnt even list them in the test results. That does bring me to the question though why the tool validator doesn’t see the WordBay links? Is that because of the base 64 decode? Is there any way to turn that off and hence have the validator see and analyze the original links? I’m not sure I want this decoding going on anymore anyway (talking about transparency). Btw, all my other Ebay links are actually “seen” by the validator and whatever page I check, these come up as working correctly. So in the end my fingers point to WordBay/EPN again….
Somehow the first half of my above comment didnt get posted? Its most important, so here again:
>>Dennis: I’ll bet you have geo-targetting turned on?
707-53477 is the geo code for Germany while 711-53200 is the code for the US, but both links point to the same item.
WHOIS on your domain puts you in Germany, so if you are viewing your wordbay site from your hometown you would get German geo code.<<
Chuck, thanks for your detective work. It is correct that Im located in Germany. But since I have geo-targeting off in the WordBay settings and have set the US as Referral locale as well as ebay Site ID, shouldnt WordBay generate the links with the US code? Item location I have set for “any country/region” with geo-targeting override off.
Also, let’s not forget that “pub” code - it shows up in any type of Link Generator link. Whats up with that? Is it vital?
eBay does not pass the pub code in RSS feed links. Generate an RSS feed in your eBay affiliate account portal and view the links. From what I’ve seen it’s not vital to getting the click tracked.
Check out the new post if you have not already. it answers some of these questions: http://www.itsgottabered.com/wordbay/2010/new-version-125-semi-critical-rss-changes-and-geotargetting-now-definitely-off/
The conclusion on the tracking issues is still… inconclusive, but I have done everything reasonably in my power again to investigate, see the post.
Regarding “encoding” links, that feature was included for SEO purposes, since I figured Google wouldn’t be favourably inclined towards lots of “rover” links, but I think the point is moot by now, WordBay and the eBay feed have plenty of other things to give their presence away, so I will consider making the encoding optional. That will also give you a chance to validate the links.
However, there need be no concern about EPN disapproving - the topic of link cloaking frequently comes up and the general conclusion has always been that the TOS do not prohibit cloaking, they merely prohibit misrepresenting the destination of the click. As long as you are being clear to your visitors that they will be taken to eBay I don’t think there is an issue.
Thanks for the update, Mark! I’m wondering though how the encoded links can actually have an SEO benefit since they are all nofollow? I mean of course its vital that they are nofollow (since they’re actually rover ebay links) but doesnt that mean that the google bots dont look at the link html at all, let alone “do something” with it?
p.s.: I would definitely welcome the option to choose between coded or raw links.
As for the pub code, I had inquired about it on the EPN forum and the last poster said this: >>”I believe it is your main account number”
Indeed it is - it’s your ePN publisher account number. Did you get a 1099-MISC form from ePN 5 weeks ago? You’ll see the same number on that form in the “Account Number” box.
To elaborate on what alssoftware said, yes, there are 2 concurrent ePN affiliate link formats being supported by ePN (perhaps more than 2?). The old one doesn’t have the publisher ID in it, while the new one does. The old one is still returned by the eBay API, for example (last I checked, a couple months ago), while the new one is returned by the Link Generator and includes more parameters that ePN likes to use for various reasons. This ePN blog post has more details on the latter. <<
The link for that blog post is here: http://www.ebaypartnernetworkblog.com/en/hints-and-tips/new-link-generator-tool-additional-information/
Its quite interesting too as it breaks down all these parameters but whats confusing is that it doesn’t go into the RSS difference at all. As you can see from the last comment on that blog post, its still causing confusion.