Referrer and Browser reports
The Reports page in the management console is generated based on logs of the requests that we received for assets in your account, and reports are available for time periods in the last 90 days (with up to 30 days in each report).
The reports include aggregated information about the top assets for the selected time period, including the option to view the results based on the number of requests or bandwidth used and to see breakdowns based on the referrer sources, web browsers used, country of the requesting IP addresses, the transformation options used, file formats returned, and other properties.
N/A in the results
If you see that under "Top Referral Domains" or "Top Referral Pages", that "N/A" is one of the top listed Referrers, this means that the requests arrived without a value in the HTTP `Referer` header, and as a result there's no data available for use in the report, which makes it difficult to give a precise answer for where the requests came from.
Similarly, the Browser section is based on the HTTP User-Agent header, which is used in HTTP requests to identify the browser or other software that was used to make the request.
By far the most common reason for requests without those fields set is if the files are being used in a native mobile (iOS or Android) app, because requests from such apps won't typically send a Referer on their requests, nor set a User-Agent header.
Most often these requests are from mobile apps in the normal app stores, but could also be from apps used in Kiosks, on advertising screens, used internally at your company and not publicly distributed, etc.
You can write your native apps so that they send a Referer or User-Agent header to help categorize their requests, and this may require you to change which libraries or frameworks you're using to load images.
Other common reasons to see a lot of traffic with no `Referer` or `User-Agent` set include:
- Requests from proxy servers or a cache in your system.
- Command line tools like "wget" or "curl" used for testing or in your development processes.
- Synchronization operations to or from a product management system or CMS.
- Image URLs being used in an another service's API or imported to another system
- URLs used in the metadata of links shared on social media sites which make a request for the image to use as a thumbnail or preview on their service.
- Ads which use the images from your account as part of the creative and which were uploaded to Google, Facebook, Twitter, or other advertising networks.
- Use of the images for products that are in a product feed such as Google Shopping or Facebook's Product Catalog feature.
- Users opening an asset URL in a new tab or new browser window.
- Privacy extensions or plugins which block Referer headers being sent by web browsers
Root of domain appearing in Top Referral Pages
You may also see that the Referer domain is set, but the "Top Referral Pages" section shows most or all of the requests are from the URL of the root page of your domain (e.g. https://www.cloudinary.com ) instead of a more specific page (like https://cloudinary.com/documentation/cloudinary_guides ).
The most likely reason for this is if the requests come from users whose browser is using a Referer policy of origin, origin-when-cross-origin, strict-origin, or strict-origin-when-cross-origin.
Many modern web browsers use a default policy of `strict-origin-when-cross-origin` meaning that only the origin domain is set in the Referer header when the request is being made to a different origin (e.g a webpage on www.example.com using images from res.cloudinary.com )
The Referrer policy may be set using HTML tags, the headers sent by your web server, or as a browser setting.