1h ago
Suggestion to Improve Compatibility and Safety After Template / Option Updates
Background
When “Save personalization data before adding to cart” is enabled, Customily saves the customer’s previous personalization inputs and attempts to restore them when the customer returns to the product page.
According to your explanation, this data is primarily matched using Option IDs, Layer IDs, and Variable Names.
Therefore, when a merchant makes significant changes to a product’s Template or Options — such as modifying, deleting, or reusing IDs — there may be risks such as:
Old customer data being matched to the wrong new fields;
Personalization data being restored incorrectly;
Rendering issues in the storefront preview;
Customers seeing information that does not match what they originally entered.
At the moment, there does not appear to be a complete ID Mapping / Version Reconciliation mechanism to handle compatibility between old and new versions.
Suggestion
I hope Customily can introduce a safer compatibility mechanism at the product level.
If the system detects that the Template / Option structure has changed and cannot confidently determine that previously saved customer data can still be mapped correctly, I would strongly prefer that:
The previous personalization data is not restored or displayed at all, rather than being incorrectly matched and causing wrong data or storefront rendering issues.
For example, when safe matching is not possible, Customily could consider:
Automatically ignoring incompatible historical data;
Clearing the relevant previously saved data;
Or asking the customer to re-enter the affected personalization information.
From both a merchant and customer perspective, not restoring old data is much safer than restoring incorrect data.
I hope the team can evaluate whether this compatibility and protection mechanism can be improved at the product-design level, which would also help reduce the risks and testing workload for merchants when updating Templates or Options.
Pending