01 - Case study: product analysis, data work, and recommendation design

Product journeys were hiding in order history.

This case study describes work performed in a Business Analyst role: studying product orders, organizing the data, and designing a prototype to estimate what customers might buy next. An AI assistant helped with development, but raw customer records were not provided to it. The prototype's final production deployment was not verified after the engagement ended.

This case study describes real implementation work on model design, analytics, data flow, and AI-assisted development. Final production deployment status was not verified after the engagement ended.
About the AI AssessmentView Case Studies

Engagement title

Business Analyst

The work extended into pipeline design, modeling, analytics, and technical handoff.

Recommendation approach

Estimating likely next products from purchase history

The approach looks for patterns in what customers bought and what they bought next.

AI delivery pattern

AI-assisted development, with raw records kept separate

Names, account details, raw records, and database access were not provided to the AI assistant.

Prototype status

Checked prototype and analytics handoff

The engagement ended before anyone verified a production launch.

02 - Business Needs

Customers followed product paths, not just repeat orders.

CellCore sold products through practitioners and directly to consumers. Products could be part of a bundle or a multi-step plan, so a customer who did not buy the same item again might still be continuing along the intended path.

Practitioners

Needed to understand which product a patient might need next and where they stopped following a product plan.

Marketing teams

Needed to tell one-time buyers from customers who continued to another product, so outreach reflected what people bought.

Product teams

Needed to see which products were related and where bundles could make sense.

Business leaders

Needed a clear view of which products sold, when customers stopped buying, and where the customer journey broke down.

03 - The Problem

The challenge was to make sense of messy order histories well enough to tell whether customers stopped buying, restocked an item, or moved on to another product in their plan.

Rather than use a recommendation model that was hard to explain, the work began with clear rules for how orders and product sequences were counted. This made the results easier for business teams to understand and for engineers to check again.

04 - How AI Helped

AI assisted the work without receiving raw customer records.

An AI assistant helped draft database queries and analysis code, check results, find errors, and prepare documentation. It was not connected to the live database and did not receive raw records.

Allowed

Data layouts and cleaned examples

Enough detail to help draft database queries, analysis steps, and checks without sharing customer identities.

Allowed

Business rules and unusual cases

An AI assistant helped with implementation and explanations while people remained responsible for product decisions and risk.

Excluded

Raw customer records or account access

The AI assistant did not connect to the live database or receive names, email addresses, phone numbers, addresses, or sensitive wellness notes.

05 - Preparing the Order Data

Clean and organize orders before making estimates.

The work turned raw order records into clean purchase groups and timelines. That gave the team consistent tables and recommendations they could review and check.
+
Gather paid and completed orders, product details, account type, sales channel, subscription status, and product-plan information.
+
Match different product codes and account for kits, bundles, cancellations, returns, duplicate orders, and date errors.
+
Treat products bought together as one group instead of guessing which was bought first.
+
Map the first purchase and later purchases by customer and product plan.
+
Calculate how recently and often someone bought, how much they spent, and whether a practitioner or bundle was involved.
+
Estimate what products may come next, how likely customers are to buy again, and why each recommendation was made.

06 - How Recommendations Were Ranked

Six ways to estimate what a customer may buy next.

The recommendation approach combined purchase patterns, products often bought together, customer groups, and clear business rules. Each part could be reviewed instead of hidden in a single score.

How the estimate works

Next-purchase pattern

Looks at the current purchase to estimate which product, group, or plan step may come next.

How the estimate works

Recent purchase sequence

Looks at the last few purchases to better reflect how a multi-step plan may progress.

How the estimate works

Repeat-purchase estimate

Helps distinguish restocking an item from moving on to another step in a plan.

How the estimate works

Products bought together

Measures which products tend to appear together in an order or customer journey.

How the estimate works

Customer groups

Groups customers by how they shop, such as through a practitioner, one time, through a bundle, or as a repeat buyer.

How the estimate works

Recommendation ranking

Combines purchase patterns, plan progress, repeat-purchase estimates, related products, customer groups, and business rules.

07 - How the Estimates Work

Simple, explainable models first.

The goal was not to win an academic benchmark. The goal was to produce something engineers could wire up, leaders could understand, and the business could trust.

Estimate the next purchase

P(next = j | current = i) = (C_ij + alpha) / (sum_k C_ik + alpha K)

This formula estimates what product may come next based on the current one. The small adjustment shown keeps a product with few past examples from being treated as impossible.

Use earlier purchases when helpful

P_final = lambda2 P2(j|s_t-2,s_t-1) + lambda1 P1(j|s_t-1) + lambda0 P_popular(j)

When enough purchase history is available, the estimate uses the last two purchases. When history is limited, it falls back to the last purchase or common products.

Estimate a repeat purchase

P(reorder = 1 | x) = 1 / (1 + exp(-(beta0 + beta1 x1 + ... + betam xm)))

This estimates whether a customer may buy the same product again. It considers timing, earlier orders, progress through a plan, customer type, and bundles.

Rank the recommendations

score = w1 P_markov + w2 P_pathway + w3 P_reorder + w4 lift + w5 segment + w6 rules

The score combines the estimates above with business rules. Each recommendation can include an explanation instead of just a number.

08 - What the Purchase Patterns Show

A customer may move to the next product instead of buying the same one again.

A single purchase gave little information about whether someone would buy again. Knowing whether a practitioner, bundle, or multi-step plan was involved changed how the next purchase could be understood.

Example purchase pattern

Current purchasePossible next productLikelihoodStep 1 / Energy + DrainageStep 2 / Gut + Immune0.31Binder categoryDrainage support0.27First direct order for one productNo purchase in window0.62

Progress through a product plan

A customer who did not buy the same item again may have moved to another product in their plan. That gives a fuller picture than a repeat-purchase chart alone.

Different customer groups

Practitioner-referred buyers, one-time buyers, bundle buyers, and repeat buyers may need different recommendations.

Products bought together

The analysis measured which products appeared together in orders. This can help inform bundles, product displays, and customer education.

How a business could use it

The recommendation table was designed to share results with reporting tools, customer and sales systems, online stores, practitioner dashboards, or email teams.

09 - Plan for Production

A prototype and handoff, not a verified production launch.

The work included offline model design, validation, and an analytics handoff. The final production deployment status was not verified after the engagement ended.

How it could be managed

Gather updated order information

Refresh order records, product details, and account information on a schedule the business can support.

How it could be managed

Update the estimates

Recount purchase patterns, products bought together, customer groups, and the values used to rank recommendations.

How it could be managed

Check the results

Hold back new recommendations if the data is incomplete, quality checks fail, or the results change sharply from the last reviewed version.

How it could be managed

Rank recommendations

List recommendations in order and explain why each one appears, including reasons an item was left out.

How it could be managed

Share results carefully

Make results available to reporting, customer, online store, and practitioner tools only after the right review.

How it could be managed

Watch for problems and restore the prior version

Track recommendation usefulness, sales, data coverage, changes, availability, and complaints. Keep the last approved version ready to restore.

10 - Privacy and Review

AI accelerated the build. It never became the system of record.

The project shows how AI assistance can support implementation while people retain responsibility for privacy, governance, and deployment decisions.
+
No personal data provided to AI. The AI assistant used data layouts, business rules, made-up example rows, and cleaned excerpts.
+
Use coded IDs. Customer and order records should be linked with coded IDs instead of names.
+
Limit data access. The analysis needs order and product details, not customer identity records.
+
Review before sharing. A person should review recommendations before they are shared with practitioners or customers.
+
Watch for changing results. Minimum data checks, clear product lists, and regular monitoring help catch changes that could make recommendations less useful.
+
Production status was not verified. The work ended with a tested model design and analytics handoff.

11 - Skills Shown in This Work

Planning, data preparation, analysis, and recommendation design for one business problem.

Demonstrates

Planning the work

Turned a broad business question into clear outputs, ways to use the results, and limits on what the model should do.

Demonstrates

Preparing the data

Designed repeatable steps to clean orders, group purchases, and put them in the right sequence.

Demonstrates

Finding useful patterns

Used order history to show how customers moved through product plans, where they stopped, and which products were related.

Demonstrates

Designing recommendations

Selected explainable methods for purchase histories and defined how to check their results.

Demonstrates

Using AI with privacy limits

Used an AI assistant to help with queries, code, error checks, and documentation without providing personal data.

Demonstrates

Planning for reliable use

Outlined how to review results, explain recommendations, monitor changes, and restore an earlier version if needed.

12 - Work and status

Completed work, with status clearly stated.

This case study describes the completed model design, analytics work, AI-assisted development, and handoff. The prototype's final production deployment was not verified after the engagement ended.

Work described in this study

Model design, data flow, transformation approach, ranking logic, validation, and AI-assisted development using sanitized information.

What was not verified

Final production deployment, medical decision-making, or access to systems and data that were not part of the work.

Start Here

Understand the business problem before choosing an AI solution.

If your business has a data or workflow problem, contact Life Tap Labs to discuss whether a custom Workflow may help and what needs to be understood before work begins.

About the AI AssessmentView Case Studies