Product teams rename a checkout, an onboarding step, or a wallet top-up because the words on the screen have gone stale. The ticket usually lives with design and copy. The event string is treated as an implementation leftover. Weeks later the funnel has two entry names and the weekly slide cannot say which screen the shopper actually saw.
In the April retail case we later wrote up for a client story, Android and web shipped checkout_begun with the new header. iOS kept checkout_start because the analytics line item was not in the visual ticket. Both events were “healthy” in isolation. Together they split a funnel that leadership still read as one sequence.
What to check the week a screen is renamed
List every event that uses the old screen name as a property or as the event string itself. Ask engineering whether the old name is still compiled. Ask analytics whether any saved report filters on the old string. If both answers are yes, you do not have a rename. You have a fork.
Parser event validation will catch the fork if the sample covers both operating systems after the store release. It will not catch a rename that has not shipped. That is why intake asks for the date range and the release calendar, not only for a pile of names.
Do not delete the old name on the same afternoon
Historical series still belong to the old string. A taxonomy cleanup can map one name onto the other without pretending the April traffic happened under the May label. Deleting first makes finance ask why 2025 vanished. Mapping first keeps the argument about the product, which is the argument you actually wanted.
If a rename is already in flight, send the old name, the new name, and the store dates with your enquiry. That is enough to start a validation pass.