Add rollup guide

[estherk15]

What does this PR do? What is the motivation?

• Add a new guide to understand rollup functions and cardinality
• DOCS-9413

Merge instructions

Merge readiness:

• Ready for merge

Merge queue is enabled in this repo. To have it automatically merged after it receives the required reviews, create the PR (from a branch that follows the <yourname>/description naming convention) and then add the following PR comment:

/merge

Additional notes

[github-actions]

Preview links (active after the build_preview check completes)

New or renamed files

• https://docs-staging.datadoghq.com/esther/docs-9413-rollup-cardinality-guide/dashboards/guide/rollup-cardinality-vizualizations

Modified Files

• https://docs-staging.datadoghq.com/esther/docs-9413-rollup-cardinality-guide/dashboards/functions/rollup
• https://docs-staging.datadoghq.com/esther/docs-9413-rollup-cardinality-guide/dashboards/guide/

[edanaher]

Thank you for writing this up! It keeps the spirit of my original document, but feels much more polished, professional, and organized.

I do have a couple suggestions; if you disagree, I'd be happy to have a conversation either here in the PR or on a short call if you think that would be more productive.

[edanaher]

This section feels pretty vague and not particularly helpful to me, but I'm not sure how I would improve it.

I'm also not the target audience for this, so I'll trust your judgment.

[janine-c]

My 2¢ is that this section feels more theoretical than you would expect after reading a heading like "solutions and best practices."

I'm wondering if we could remove it altogether, since I think all three of these points are already covered earlier in the topic. Otherwise, maybe we could introduce some more examples here with some specific calculations for readers to follow along with, so the advice feels more actionable. If you do the latter, I might incorporate it into the above sections because I think it could aid the conceptual understanding - I don't think I'd collect it at the end, in case readers don't scroll that far 🙂

This one is tough to get right! It's necessarily way into the weeds because it's a counterintuitive nuance that users very understandably struggle with, and that's super difficult to explain away.

[estherk15]

Thanks! Yea, that makes sense. It seems like a repeat of what was already covered so I'll remove.

[cswatt]

Added DOCS-9842 to track review.

[janine-c]

Suggested change

	Suppose, over the course of a week, 2,000 users on a site experiences a total of 6,000 error events, while the remaining 22,000 users don't experience any errors. Since a user's multiple errors may occur nearly simultaneously or in different hours, there could be an average of as many as 35 users experiencing errors per hour or as few as 11.
	Suppose, over the course of a week, 2,000 users on a site experience a total of 6,000 error events, while the remaining 22,000 users don't experience any errors. Since a user's multiple errors may occur nearly simultaneously or in different hours, there could be an average of as many as 35 users experiencing errors per hour or as few as 11.

[janine-c]

I found this a bit hard to follow - I noticed that the heading says "calculation," but it's hard to follow where the numbers are coming from (35 or 11?) because I don't actually know how these values are being calculated. It's likely obvious for someone who has the intuitive math skills that I lack, but I worry that the cognitive load for this section is pretty high, and that makes it harder to see what the takeaway should be.

I wonder if it would be easier to follow if we introduced the takeaway first, then supported it with numbers, so the focus doesn't get bogged down in the details?

[janine-c]

My 2¢ is that this section feels more theoretical than you would expect after reading a heading like "solutions and best practices."

I'm wondering if we could remove it altogether, since I think all three of these points are already covered earlier in the topic. Otherwise, maybe we could introduce some more examples here with some specific calculations for readers to follow along with, so the advice feels more actionable. If you do the latter, I might incorporate it into the above sections because I think it could aid the conceptual understanding - I don't think I'd collect it at the end, in case readers don't scroll that far 🙂

This one is tough to get right! It's necessarily way into the weeds because it's a counterintuitive nuance that users very understandably struggle with, and that's super difficult to explain away.

[estherk15]

Thanks! Yea, that makes sense. It seems like a repeat of what was already covered so I'll remove.

[estherk15]

@janine-c I tried to simplify this section, but essentially it's just a more in depth example that builds on the above example. Does it make the issue more confusing and would it be better left off the document?

[janine-c]

I don't think you need two separate sections! I like that you have a more in-depth example that illustrates a bunch of pitfalls at once. I think you could probably replace the simpler one with the chonkier one :)

[janine-c]

Hey Esther, this looks great! It feels a lot simpler and less theoretical. I have a few remaining questions because this is so far outside of my domain, but feel free to ignore them if you think that someone who's already in this section of the docs will already understand what's happening there.

Your topic feels overall a lot more practical and easy to follow compared to the last draft I looked at - nicely done! I think users will come away from it feeling a lot more empowered to understand their data 👏🏻

[janine-c]

Suggested change

	When aggregating data using the rollup function, the results can be counterintuitive. For example, the sum of hourly distinct user counts can exceed the count of distinct users over a full day. This is because users appearing in multiple hourly buckets are counted once per bucket but only once across the entire day.
	When aggregating data using the rollup function, the results can be counterintuitive. For example, the sum of hourly distinct user counts can exceed the count of distinct users over a full day. This is because users appearing in multiple hourly buckets are counted once per bucket, but only once across the entire day.

[janine-c]

There are a few terms here like "scalar value" and "direct query" that I'm not familiar with, so I'm not 100% I understand this example. I wonder if we could make it sound a little more like the previous example? Maybe something like:

Suggested change

Visualizations by default show the sum of rollup values across intervals, which can lead to discrepancies between the sum and a scalar value representing the entire time frame. For instance, a graph might display a sum of 125 for hourly rollups, while a direct query shows 121 for the same period. This is due to sessions or users being counted multiple times across hourly buckets but only once in the daily rollup.

By default, visualizations show the sum of rollup values across intervals, which can lead to discrepancies between the sum and a scalar value representing the entire time frame. For instance, a graph might display a sum of 125 users who visited your website in an hourly rollup, while a direct query shows 121 users over the same period. This is due to sessions or users being counted multiple times across hourly buckets but only once in the daily rollup.

Reading it again, I think I'm confused because both of these numbers are over an hour-long period, so I'm not sure where the daily rollup part comes in 🤔

[janine-c]

I don't think you need two separate sections! I like that you have a more in-depth example that illustrates a bunch of pitfalls at once. I think you could probably replace the simpler one with the chonkier one :)

[janine-c]

Could you explain this part:

Daily error rates fluctuate, with hourly figures ranging from 11 to 35 users facing errors. Additionally, on an hourly basis, there are around 1,000 distinct users encountering errors weekly

I can't intuit the difference between an hourly figure and the number on an hourly basis. Or how on an hourly basis, users encounter errors weekly? 😵 It might need some more dumbing down - I wonder if the difference here is that there's a difference between how the time frames are counted, and how users can choose to have that data display? Or maybe it's something else?