Tracking asset downloads/bandwidth

This might be a somewhat rare use case with Contentful, but I’d be interested to hear people’s views how they would handle it.

Let’s say one has a file in the media library and wants to track how many times that file was downloaded or how much bandwidth was spent to deliver that file. This would be easy if the file was on one’s own server. No problem, just check the access logs. However, since the file is hosted in Contentful, such logs are not available to the user (at least to my knowledge).

Can anybody think any kind of even remotely feasible way to do this? The only thing I can think of is some kind of redirecting hack. For example is a script that logs the hit and redirects to

That solves logging the hits, but not the bandwidth tracking. So…any ideas, guys? :slight_smile:

1 Like

Hey @teemu.tammela1 ,

I wouldn’t recommend using a redirect (or even worse: a proxy), as this might influence current behavior, in case some consumers don’t follow redirects directly (e.g. cURL requires a special -L flag).
It also introduces a single point of failure on your end, thus quite defeating the purpose of Contentful’s high availability .

Currently I don’t think there’s a good way to have this exposed, but it definitely is tracked in an accumulated manner for billing & fair-use tracking.

As this also involves the different CDNs to get precise statistics regardless of the region in the world, this should be handed in as a feature request, which can then be handled by the team in charge in a way they consider useful.

I’m sorry to disappoint you here, but maybe someone else has a more creative solution :slight_smile:


1 Like

Yup, I’m not too fond of the redirection approach myself exactly for the reasons you mentioned.

I think a proxy might be the only real way to get what you want. With respect, I don’t really agree with Stephan’s reason for not proxying because your site document or any other services you host are a single point of failure as well. You have to manage that like you manage everything else. I do like taking the pressure of my own web server by letting Contentful handle the images (and that’s what we do) but if it’s a hard requirement to do what you want then you need to host those images.

Even though I agree that it’s a better technical solution to let Contentful host images, a big issue for Contentful is that their billing is based on serving them.

Even though it’s part of our billing, it’s neglect-able compared to the features we provide by ourselves like spaces, users, etc. In fact it’s just there so you don’t stretch our infrastructure too hard without additional costs.

So the recommendation was a purely technical (I’m a backend dev btw, not a sales/marketing person) and even though you can handle it yourself that doesn’t mean you should.

If it’s a hard requirement, sure, you need to solve it, so you might need to do it yourself. In case you have the manpower to operate such solution, that’s an option. But I guess even then there’s a provider which can do that better for you, than having your own servers and trying to distribute this with a CDN. (In fact we’re using multiple different ones to really be globally distributed, to have fallbacks in case a provider has an outage, etc.)

If you go with this approach, you can still have fields in Contentful which contain links to the external providers’ files (assuming they’re specialised on files only). We market ourselves as a “content microservice”, so nothing holds you back from integrating with other third-party services to solve your specific use-case.

Maybe my first response sounded too much like walled-garden, then I’m sorry for this. That was not my intention - it was purely informational of the current state about what we are capable of providing to you. Actually I’d be interested to see such an integration, and in the long-term I think we should provide such metrics as well.


1 Like