MariaDB - Slow GROUP BY on 55 Million row table
Some bugs:  Each time range leaves out one midnight.  Your first example is 2 months minus one second; nowhere near one "quarter"  The second is one quarter minutes one day minus one second.

As for the attempts you have made in indexing, this one is probably optimal:  (occurredAt, userId, trackId).  Rationale:


The first column completely handles the filtering for the WHERE.
The rest of the columns make the index "covering", so only the index will be used.


Note:  There could be caching issues that confuse the results of timing tests.

The reason the query with an id range may have seemed faster could be caching.  I would not trust it to be faster.

This may work better:  INDEX(userId, tracked, occurredAt)  I say "may" because it depends on a messy optimization that your version may not include.  Note that it could use the first two columns to handle the GROUP BY, thereby avoiding a sort.  And it is "covering".  But it depends on being able to hop through the index.  Suggest getting EXPLAIN FORMAT=JSON SELECT ..., which might provide enough clues.  Or Optimizer Trace.

A big Yes to a summary table.  Depending on the distribution of the data, I might add rows to it each night, then tally up the rows to get the quarterly total.  (This would let you get monthly or weekly tallies, too.  And they would be equally fast.)

A Rule of Thumb when designing a Summary Table:  Aim for one-tenth as many rows in the summary table as in the 'Fact' table.  (If the 'averge' user listens to only one track per day, daily subtotal would be useless.)

More on summary tables:  http://mysql.rjweb.org/doc.php/summarytables

Another issue...  What is the setting of innodb_buffer_pool_size; how much RAM do you have; and how big is the table?  (I would guess 5GB for "Data_length".)  If you have a small machine, we need to discuss shrinking the datatypes, normalization, and tuning.