Understand using something to measure throughput will give you what is actually being downloaded (and uploaded) - this actually may be very accurate.
What concerns me is that the compression scheme may be expanding things (like images) a lot larger than they were before they were sent. When you deal with tons of little avitar images on social media (not to mention the amount of image attachments), this can really add up a lot faster than you're used to.
I actually have worked out a high level procedure to test this theory, but just not had the time to work out the details of avoiding things like browser caches and content delivery networks that would make it unaccurate... plus, did I mention the time to do it... lol.
Theory may be all washed up and I might go down in flames, but at least I'll be able to finally put some of this data issue to bed.
Anticipating doing something some time next week... this one's already shot.
Incidentally, and just to be perfectly clear on this... this is just a gut feeling about usage on my part, based on certain experiences I've had using the devices I have.
It's by no means meant to be an authoritative statement that there is in fact a compression issue with images. I'm just doing this in an unofficial capacity to satisfy my own intellectual curiosity.
Unofficial, unscientific streaming test:
Just used Spotify on my iPhone outside to play a regular ~55 minute album at standard quality (I think they use 128kHz faac for that) which used ~70MB. That seems about right.
This isn't the ultimate test I was planning using images, just a quick measurement from a target of opportunity while other house members weren't bogarting bandwidth. Really didn't think streaming audio was an issue, tbh, and this provides some confirmation of that.