Segmentation approximate count, cache that number

[Anonymous]

When you click on a segmentation to get an overview, it gives you a rough number of leads per segment:

Segments (Approx. Count):

In larger instances I've seen those numbers take quite a while to load. Considering we call them as approximate counts, it would be great if we could go longer between caching them so that we could look at them and get a quick, rough estimate.

[Anonymous]

It's not actually cached, it's a realtime query with lighter constraints. In the future we could try and speed it up though.

[Mark_Farnell]

whilst we assume that the segmentation changes in near real time, depending on the campaign queue, it does mean this delay means we can't use the segmentation as an easy reference to check numbers.  If this could be speeded up, and have the soft deletes excluded, it would help.  Based on my instance I'd say the soft delete was a lot longer than 30 days - we moved 200,000 in August and looks like they are still being counted.

[Luis_Paez3]

I agree, we're seeing deleted records being counted on the "approx. counts" section of Segments. This makes this feature unusable, because they don't reflect current reality.

For me, this is not an Idea. This problem is a bug. No where does it describe these counts as counting deleted records - that idea is somewhat counter-intuitive.

[Denise_Greenb12]

When you first approve a Segmentation, the Approximate Count feature is useful as a quick check for any needed tweaks. After that it's useless or worse. For example, I approved a new segmentation yesterday that was carefully build so that the Default segment would be empty - and it is. But the Approx Counts view shows it has 3,050 people in it.

I said "or worse" because drastically off numbers can cause alarm - and even for those of us who know these approximations can be very wrong, it forces us to waste time verifying the actual numbers.