We’ve just ended our trial and reverted back to the original image URLs. This should resolve any issues related to this (flag counters, Cloudfront caches, broken images etc) and give us some time to have a think about potential solutions for those problems before we turn it on again.
Thanks, don’t worry, I deleted it when it didn’t showed up during the trial period, that’s why you haven’t seen it. I have just read the announcement about the trial ending up, so I have put it back and now it’s working.
I am having problems with the flagcounter tool that I am using. I am getting weird readings since yesterday. I do not know if this is related. Please let me know. Kind Regards Snowcake
What was weird about the readings? Were they heavily skewed to one country? We’ve turned this feature off now so your readings should go back to normal.
The image counters we’ve looked at so far all respond with no-cache in the Cache-Control header. This tells Cloudfront not to cache the image and always request it from the origin server, so page view counting should still work.
This feature has completely disabled my pixel-tracking which tracked visits on my items. Even if I’d change the cache headers behaviour on my tracking server, I wouldn’t be able to see the original IP address and referer which are essential for tracking the visits.
Is this deliberate to disable authors from possibility of tracking their visitors? If so, that it’s not a technical issue, but I rather wished that we were given a possibility to set up a pixel tracking on sale confirmation pages, instead of disabling all tracking possibility.
It’s a fact that the authors are supposed to do some promotion of their items on their own, not only rely on the marketplace to do the job, so how are we supposed to promote without tracking?My suggestion is, that we might use this sort of proxy for all regular images, but the author might be given a possibility to set up a pixel tracking explicitly in profile settings, by adding an URL of a tracking image which would be automatically added to each page (and be required to be very lightweight in order to not decrease the page loading time).
The original IP address is forwarded on in the X-Forwarded-For header, although the referrer would probably be blank. The aim here is to improve page load time, we certainly do not want to prevent authors from gathering their own web analytics. We have some ideas on how to solve this and we’ll be sure to let everyone know what we come up with before turning this on again.
My profile and description images have all but disappeared today. How can I fix that?
We’ve turned this feature off now and your images are back, sorry about that! We’re investigating a fix for the issue, which seems to be related to images hosted on google drive.
Is there a way to force-refresh the cache, or force the CDN to grab images again without adding v=2 or something similar to the image URL? We have a lot of items and on all of them the images are broken because they were picked up like that. We fixed the issue but the default cache time is 10 days so ….
The most reliable way is to change the URL by adding a version number to the image filename. We’re investigating other ways we could enable the cache to be cleared.
My counter is working again, yaaaayy. Everything is back to normal. And yes, it was only showing one country (USA/Virginia). I hope that testing has to come to a final end. Or will there be the chance, that you will continue with such tests in the near future? Hopefully not Thank you stevehodgkiss!
Kind Regards Snowcake
My counter is working again, yaaaayy. Everything is back to normal. And yes, it was only showing one country (USA/Virginia). I hope that testing has to come to a final end. Or will there be the chance, that you will continue with such tests in the near future? Hopefully not Thank you stevehodgkiss! Kind Regards Snowcake
We will revisit this again in the future (although I’m not sure when), and before we do another trial we’ll be sure to let everyone know what the solution is for analytics images