Thanks again for keeping this crucial thread alive!
I’m so curious about the drop in #z2z. I wonder if zecwallet has seen a corresponding dip in adoption metrics, @adityapk00?
It’s curious to see the #z2z txn rate drop while shielded ZEC is climbing steadily. I’d love to hear anyone’s theories.
@garethtdavies I’d love to see charts of total txn fees coming from (a) fully #z2z and (b) any txn involving Sapling. Any chance you could add that?
I can add that, but a quick back of the envelope would simply assume 0.0001 for those fees so the transaction volume would be a very good estimate from the total tx with a shielded component chart.
One additional point I forgot to mention was that July was also the first time there were no fully shielded Sprout transactions - it had been trending to zero for some time, but this was the first time it happened.
From the first Zcash Gardening Club, watch 1 minute of the video, starting here (6 minutes 55 seconds):
Simultaneous with the ZECpages presentation, there were some comments in the Zoom chat that indicated that the ZECpages-related #z2z volume was indeed substantial for two months.
So I believe that a significant percentage of all #z2z transactions are coming from ZECpages, and large increases or decreases in #z2z transactions are attributable to changes in ZECpages usage.
Zecwallet lite or lightwalletd doesn’t log any user metrics, so I can’t really speak to usage changes.
There has been no change in the download rate (In fact, has increased slightly)
Coincidentally, a couple of minutes ago Balaji Srinivasan just praised zecboard on twitter: https://twitter.com/balajis/status/1290362181670727680 He has a lot of twitter followers, and he is highly influential on other influential people, so maybe zecboard traffic will pick up. 
Also when trying to find the patterns in the tea leaves of shielded usage rates, don’t forget that some ECC employees were experimenting with automated donations in June. Runaway Python scripts could easily have accounted for some of the spike of z2z traffic in June.
Re: reading shielded tea leaves
Maybe ask @afterconnery & @zcashvr for the relevant z2z news data? There were some shielded transaction chart changes around the time the project was active & when it concluded. Maybe its useful? ZECpages public post activity has been fairly constant. Thank you for the project shoutouts & reposts!
I expect a significant contribution from the implementation of Heartwood (payout to miners). It will be interesting to see the August results.
At the height of the z2z newsletter we were sending out anywhere from 15-24 txns a day. Also, it was back in April or May I send out ~ 200 txns in one day b/c of something Leto said on Twitter 
. I’m going to soon start working on a GUI for the newsletter. We’ll see how that goes. If you want to donate to that cause hit me up @ z2z.to/shonondray
Here’s a proof of concept for a realtime dashboard with this data: https://garethtdavies.com/zcash-dashboard
Data is currently updated hourly (though there is a 20 block delay to avoid reorgs).
There are some filters on the right (highlighted in the screenshot below), so you can limit the output to post-Heartwood or block heights, types, etc.
There is a simple chart for shielded coinbases, but as there aren’t any yet, I’m showing transparent coinbases as a % of all coinbases since Heartwood). I’ll update this when we see one in the wild.
Thankyou for this @garethtdavies
This is a general comment about dashboards and graphs with data bucketed by time period:
Please don’t show partial data in the last month (or whatever time period) as though it were a complete month! Just omit the last incomplete time period.
(I know the underlying APIs often require extra effort to do that. IMHO that’s a bug in those APIs, but the extra effort is worth it.)
Concur! I was totally biting my tongue and not saying this because I didn’t want to complain, nor to give extra work to Gareth, but it is really easy for people to misunderstand representations which show an incomplete bucket in the same visual way that it shows complete buckets (Figure A below).
Here’s are a couple of ideas for better representation — no idea how much work it would be to implement in this case:
Whenever you’re visually representing a series of buckets as stacked bar charts, and you have an incomplete bucket (like a month that is not yet over) as one of them, make that one thinner proportionally to how incomplete it is. Like, if we’re halfway through the month, make that bar be half as wide as the bars representing complete months. Maybe show a dotted line showing how wide it will be at the end of the month. (Figure C)
Another related concept is show a dotted-line linear extrapolation, i.e. if you’re halfway through the month, and you have 1000 items in the bucket, then show the 1000 items in the same color as the items from completed buckets (previous months), plus show a dotted line outline to indicate that, if the same rate holds for the rest of the month, that there will probably be 2000 items in this bucket by the end of the month. (Figure D)
Might be possible to combine both ideas.
Just some thoughts. Would be curious what Gareth thinks. Obviously it would be easier to just do what Daira suggested and omit incomplete buckets from your visualization. That would definitely be better, IMHO, than showing incomplete buckets side by side and visually identical to complete buckets. You could perhaps show the latest, incomplete bucket separately somehow, so that it is visually distinct from the complete buckets. (Figure B)
P.S. Ooh, you could even conceivably have that last, incomplete bucket be a dotted-line outline which is partially filled with mini-buckets. For example, if the last bucket is a month that is halfway over, it could be a dotted line that is one-month-wide, and it could have 15 little mini-bar-charts in it each of which is 1/30th of a month wide, showing the 15 days that have already passed and already have data. i think that should result in a visual indicator to the reader that both (a) shows them that this isn’t the same kind of data as the complete-buckets-data, and (b) gives them an indication or a prediction of where it is likely to end up. (Figure E)
P.P.S. This is probably a job for whoever makes the graphing libraries that Gareth is using rather than a job for Gareth. 
I actually considered recommending the extrapolation approach, and decided against because it can easily be misleading or cause scaling errors. For example, if you’re extrapolating a single day’s data to a month, then it won’t be at all accurate, and it might interfere with the scaling of the whole graph if the mis-estimate is too large.
Here are sketches of all the possibilities I mentioned above.
Figure A:
Like Daira says above, the linear extrapolation ones (Figure D and Figure E) can produce really inaccurate predictions.
If I were doing this today I guess I would go with Figure B, but it would be cool if some Edward-Tufte-loving dataviz wizard could come up with a good solution to this common problem.
Ok last idea and then I’m going to go back to my actual job.
Figure F:
This one is potentially actually implementable, and it avoids both the “partial buckets misrepresented as complete buckets” problem from Figure A as well as the “sketchy linear extrapolation” problems from Figures D and E. Not sure if it would actually be a good and useful representation in practice, compared to Figure B.
I personally would much rather see actual complete data from the actual chain, and nothing else. It’s far too easy to misread or misinterpret anything else, and I would hate to see any decisions or opinions be made based on extrapolations on data that has frequently changed over time. Hopefully no decisions are being made that require up-to-the-day information on this anyway!
Great feedback, thanks. This is why I always published complete monthly data as per the original post
I agree with this and I’ve taken the dashboard down. It was intended as a POC, and as a result is very limited by the software used so it simply isn’t feasible to implement any of the suggestions as is. The plan was to develop further using a fully developed charting library (as that is where the bulk of the work is) using the same backend but I’ll save that for (much) later or perhaps someone can use this example and the above discussion to implement it in an existing solution.
@zooko: This data seems very important. While it’s been very kind of @garethtdavies to volunteer their time to maintain it, might it fall within ECC’s funding to keep it going? It is not currently possible for anyone to request ecosystem funding through the existing ZF Grants platform to do so.
Hey, do you have the CSVs for the data somewhere? I’m happy to mess around with different graphs.
I keep coming back this thread to track shielded adoption, so least I can do.
Sounds great! Here’s the raw data used which is at the tx level so it’s ~7 million rows and ~850MB. Script used to determine types is in the original post.
https://keybase.pub/garethtdavies/zcash-all-tx.csv
I’ll also continue to publish the monthly data as I have been doing, just dropping the real-time dashboard until it can be better implemented as per the suggestions above.
Updated stats for August. While monthly transactions were the highest since August last year, 90% of those were fully transparent 
A mere 1.5% of tx in August were z2z tx.
I’ve separated out shielded coinbase stats and will later show as a % of all coinbase tx when this ratio becomes more meaningful. In August there were 24 of them.
There was 1 fully shielded Sprout tx and 0 migration transactions in August. The latter is interesting given there is still ~115k in the Sprout pool.
