Reason about MAU error after user ID rehash

A product records activity using the user_id from login events, and computes MAU as follows:

• MAU (L30D) for a date d equals the number of distinct user_id values with at least one login in the inclusive window [d-29, d].

Data change event

On one particular day T, the company performs a one-time rehash of all user IDs:

• For dates before T, events use the old user_id_old.
• For dates from T onward, events use the new user_id_new.
• Each real person receives exactly one new ID (a one-to-one remapping), but your metric pipeline does not have the mapping between old and new IDs.

Questions

1. For dates whose L30D window overlaps both sides of T, how can this rehash bias the computed MAU if you naively count distinct user_id?
2. What are the maximum possible MAU overestimate and the minimum possible MAU overestimate, as percentages, relative to the true number of distinct real users in the window?
3. Operationally, how would you redesign tracking/warehouse modeling to make MAU robust to this type of ID change?

Overview: This question evaluates a data scientist's understanding of identity management, windowed distinct-count metrics (MAU), and the impact of a one-time ID remapping on measurement bias and data modeling.