Start with one workflow that costs the most manual time. Prove value there before expanding.
AI-driven personalization is different in kind. Instead of choosing between pre-written variants, the system generates a response that fits the specific user’s context at the moment they request it. This is not appropriate for every type of content, a blog post should not change based on who is reading it. But for a few specific use cases, it produces meaningfully better results than static content.
The use cases worth building are narrow. A product recommendation explanation that takes into account what the user has already browsed. An onboarding checklist that reflects the user’s account settings rather than a generic list. A support response that incorporates the user’s order history before suggesting a solution. In each case, the AI receives context that is specific to this user and generates a response that could not have been pre-written.
The architecture of a personalization plugin
Architecture steps for WordPress AI personalization.
A WordPress personalization plugin has three parts. First, a data layer that gathers the relevant user context, browsing history stored in the session, user meta fields, WooCommerce order data, or any other source that is meaningful for the use case. Second, an API layer that sends this context to the AI model along with instructions for what to generate. Third, a rendering layer that displays the generated output in the right place on the page.
The data layer is usually the hardest part to design. The question is not “what data is available” but “what data is actually relevant to what the AI is generating.” Sending irrelevant context wastes tokens and can confuse the model. The context sent to the model should be the minimum that allows it to generate something more appropriate than a generic response.
Second, an API layer that sends this context to the AI model along with instructions for what to generate.
Working on something similar?
Let's talk →Caching and cost
Working on something similar?
Let's talk →Generating a fresh AI response for every page load for every user is expensive at scale. The solution is selective generation. Generate the personalized content once per session or once per significant change in the user’s context, cache it for that session, and regenerate it when the context changes meaningfully.
For custom software built on WordPress, the caching strategy depends on what triggers a context change. A new purchase, a new support ticket, or reaching a new stage in an onboarding flow are all meaningful triggers. Time alone is not.
When not to build this
Personalization is worth building when there is evidence that the lack of it is costing you something, high drop-off at a specific point, low engagement with recommendations, poor conversion from a specific user segment. Building it speculatively, before understanding the current problem, tends to produce complexity without measurable benefit.
The simpler path: A/B testing different static versions of the content to find which works better, is often sufficient and much less expensive to operate. Consider personalization when A/B testing has run out of room for improvement.
If you are considering this for your WordPress development project, the first question worth answering is: what specific outcome are you expecting to improve, and how will you measure it?
