Event vs user property confusion: engineering solution

Send future values as the property type that matches the approved data model. Data Assistant can't reclassify the raw field, and Amplitude has no direct transformation that converts a regular event property into a regular user property or the reverse. Start from the intended type in the audit.

Plan the migration

1. Use the intended type from the audit.
2. Choose a clear target name. Reuse the old name only when analysts can unambiguously tell the property types apart in charts.
3. Add the target property to the tracking plan with its type, description, owner, and source.
4. List saved charts, cohorts, experiments, and destinations that depend on the old property.
5. Choose a migration date and tell analysts that old and new data use different fields.

Correct the source

• To move event context to a user property, update the user property before you send the next event that should use it. The new value applies to future events and doesn't rewrite earlier ones.
• To move a person-level value to an event property, include the value on every event occurrence where that historical context matters.
• If both meanings are valid, keep two clearly named properties and document when to use each.

Validate and retire the old field

1. Trigger test events and inspect both event and user properties in Event Explorer.
2. Confirm that Observe matches the new tracking-plan definition.
3. Update dependent charts and cohorts to use the target property for data after the migration date.
4. Hide or delete the obsolete property only after owners confirm new queries no longer need it. Refer to Remove invalid data for the effect of each option.

If you need one continuous historical field, a derived or computed property may bridge analysis when the existing data holds enough information. It doesn't rewrite the raw event history.