Every quarter, product teams try to piece together what customers are really saying. Reviews come from ecommerce platforms, support teams bring recurring questions and complaints, social teams flag new conversations and retail partners provide their latest sales reports. Somewhere across those sources are the signals the business needs: confusion around product use, packaging issues, emerging customer needs, unexpected use cases and differences in performance from one market to another.

The difficulty is not collecting the information. Most of it is already available. The difficulty is bringing it together in a form that can actually be analyzed. Each source arrives through a different system, in a different format and on its own reporting schedule. Teams spend time exporting files, cleaning spreadsheets, matching product names and transferring findings into presentations before they can begin to look for meaningful connections.

By the time the picture is complete, it may reflect customer behaviour from several months earlier. An emerging issue may already have grown, a new use case may have been missed or a product decision may have been made without the full context.

For consumer brands operating across ecommerce, retail, customer support and social channels, this is becoming less of a reporting problem and more of a data architecture problem. Better dashboards alone will not solve it, and neither will adding a generative AI model on top of disconnected systems. 

What is needed is an AWS architecture that can continuously ingest, normalize, enrich and analyze consumer data, while preserving the source evidence and human judgement required to turn those signals into sound business decisions.

Using Amazon S3 as the consumer data foundation

Let’s start with the data. Amazon S3 can provide the central storage layer for both structured and unstructured consumer data.

Instead of forcing every source into one rigid format before ingestion, the architecture can preserve the original data while creating standardized datasets for analysis. Raw product reviews, support transcripts, sales reports and survey exports can be stored in separate S3 prefixes or buckets according to source, business unit, geography or sensitivity.

This separation supports both governance and traceability. The original source file remains available for audit and reprocessing, while transformed versions can be created for downstream services. If a classification model or prompt changes, the organization can rerun the analysis against the original data rather than relying only on previously generated summaries.

S3 object metadata can also capture useful operational information, including the ingestion date, source system, market, language, product family and processing status. For a multilingual brand, language detection can be incorporated early in the pipeline. Feedback can then be routed to the appropriate processing logic while preserving the original text. The result is a durable consumer data lake that supports more than one dashboard or AI use case.

Automating ingestion with AWS Lambda and AWS Step Functions

Each consumer data source requires a slightly different ingestion pattern. A retail partner may deliver a weekly CSV file, whereas a customer support platform may expose an API. Product reviews might be retrieved several times per day. Social data may arrive as a continuous stream or a scheduled export.

AWS Lambda can support the event-driven components of this architecture. A new file placed in Amazon S3 can trigger a Lambda function that validates the format, extracts metadata and initiates the appropriate processing workflow.

For longer or multi-stage processes, AWS Step Functions can coordinate the workflow. An AWS Step Functions state machine could begin by validating the incoming file, checking whether the source has already been processed and separating valid records from exceptions. It could then invoke Lambda functions to normalize product identifiers, remove duplicate content, detect language and prepare the text for analysis.

If a step fails, the workflow can retry the task, route the record for manual review or write the failure details to an exception store. This is important when the engine is processing data from external systems that may change formats without notice.

Step Functions also provides visibility into the status of each workflow. Teams can see whether a retail report was successfully processed, where an ingestion failed and how long each stage took.

Preparing consumer feedback for meaningful analysis

Before customer feedback can be analyzed, it often needs to be cleaned, standardized and put into context.

Reviews may include boilerplate text, duplicate submissions, irrelevant comments or references to several products in the same paragraph. Support conversations may contain employee responses that should not be treated as customer sentiment. Social posts may mention a product indirectly through a nickname, campaign phrase or image caption.

A preprocessing layer can improve the quality of the analysis before the content reaches Amazon Bedrock. Lambda functions can remove duplicated records, standardize timestamps and associate feedback with a known product catalogue. Product names can be mapped to internal SKUs even when customers use shortened names or common misspellings.

Long support conversations can be separated by speaker. Personally identifiable information can be removed or masked according to the organization’s security and privacy requirements.

The architecture can also divide long documents into smaller text segments while preserving the relationship between each segment and its source. This allows the system to analyze individual issues without losing the surrounding conversation.

In a nutshell, good preprocessing reduces the amount of irrelevant information sent to the model and makes the resulting insights easier to validate.

Applying Amazon Bedrock to consumer feedback

Once the data has been prepared, Amazon Bedrock can provide access to foundation models for classification, summarization, topic extraction and natural language analysis.

The purpose is not to send every customer comment to a model with a broad instruction such as “find useful insights.” That approach is difficult to evaluate and tends to produce inconsistent results.

A production architecture requires narrower, repeatable tasks. One Bedrock prompt could classify each piece of feedback according to an approved taxonomy such as packaging, product performance, instructions, price, availability, scent, texture, ingredients or customer service.

Another could extract the product use case, customer intent and specific point of friction. A separate step could generate a concise summary of a support conversation while retaining the original ticket identifier.

The model could also identify whether a customer is asking a question, describing a problem, suggesting an improvement or reporting an unexpected use for the product.

These tasks can return structured output rather than free-form prose. For example, the result can be represented as JSON containing the topic, subtopic, sentiment, urgency, product reference, confidence level and supporting text.

Structured output makes the results easier to index, filter and compare with sales or operational data. It also helps the engineering team validate whether the model is following the expected format before the information reaches business users.

Moving beyond generic sentiment scores

Basic sentiment analysis can indicate whether feedback is positive, negative or neutral, but consumer decisions rarely fit into three categories.

A review score alone doesn’t always show the entire picture. A customer may love the product but still point out a problem with the delivery, while a poor rating may have more to do with unclear instructions than with the product itself. Support questions can also reveal where customers need more guidance, especially when the same issue appears across several channels.

Amazon Bedrock can be used to analyze these distinctions. Instead of assigning one sentiment score to an entire review, the system can detect sentiment at the topic level. The engine does not need to decide which response is correct. It needs to preserve enough context for the appropriate team to investigate the signal.

Structuring enriched data for analysis

The results generated by Amazon Bedrock are only valuable if they can be counted, compared and joined with other data. A JSON file stored in Amazon S3 is not enough. The architecture also needs a queryable analytical layer that can be accessed through SQL.

AWS Glue Data Catalog serves as the central repository for this layer. It defines the tables, columns and partitions, allowing multiple query engines to access the same data without creating additional copies. AWS Lake Formation can then apply granular permissions, including controls at the column level.

The table format also requires careful consideration. Customer feedback arrives continuously in small volumes, and the records can change over time. A review may be edited, a support ticket may move to a different status or a classification may be corrected by an analyst.

Apache Iceberg tables, available as a managed capability through Amazon S3 Tables, address all three requirements. They support row-level updates instead of requiring an entire partition to be rewritten. They retain version history, making it possible to reproduce an analysis as it existed on a specific date. They also compact small files automatically.

This last point is often overlooked. Without compaction, read costs can increase quietly as small files accumulate.

The architecture can be divided into three zones. A raw zone preserves the original files exactly as they were received. A normalized zone contains records that have been cleaned, deduplicated and enriched by the model, stored as Iceberg tables. Finally, an analytical zone exposes a dimensional model designed for business queries.

The shared data model is built within this final zone. Product, market, time and channel dimensions are defined once and then shared across customer feedback, support requests and sales reports. Without these common dimensions, qualitative signals cannot be reliably compared with commercial performance.

 

The time dimension requires particular care because mistakes can have concrete consequences. Each record should retain two separate timestamps: the date the feedback was originally submitted and the date it was ingested into the system.

When these timestamps are treated as the same value, loading several months of historical data can create the appearance of a sudden spike in complaints that never actually occurred. This type of error can be difficult to detect afterward because the figures remain internally consistent.

Amazon Athena can then query the tables using SQL without requiring servers to be managed, making it well suited to ad hoc analysis and dashboard data sources. For larger data volumes or a high number of concurrent users, Amazon Redshift Serverless can query the same tables without moving the data.

Partitioning the data by date and market, combined with precomputed aggregate tables for trend analysis, helps keep read costs predictable as the volume of historical data grows.

Retrieving supporting customer feedback with Amazon OpenSearch Service

The analytical layer answers questions about volume: how many comments relate to packaging, how that number changes from one month to the next and how it compares with sales. It does not answer the question that usually comes next, and that is often the most important one: what are these customers actually saying?

That is the role of Amazon OpenSearch Service. The same enriched records that populate the Iceberg tables are indexed in OpenSearch using the same identifiers. Each record includes the customer’s original text, its source, the date of the comment, the product, the detected themes, the sentiment associated with each topic, the region and any summaries or classifications produced by the model. A figure displayed in a dashboard can therefore link directly to the comments behind it.

This division of responsibilities is not simply a technical preference. It is a constraint. A search engine returns the documents that are most similar to a query, not every relevant document within a given period. Using search results as a metric produces numbers that may appear credible but cannot be reproduced reliably. Counts, trends and comparisons with sales belong in SQL. Search is used to understand, illustrate and explore.

OpenSearch allows teams to search across all sources using natural language, even when the words in the query differ from those used in the comments. The system can also support semantic search by representing comments as vector embeddings, making it possible to find conceptually related feedback instead of relying only on exact keyword matches. A customer who writes “the cap leaked in my bag” and another who reports “product all over my suitcase” are describing the same problem without using any of the same words.

Results can be filtered by product, market, retailer, period or channel, and the original source should remain accessible from every result. When the system detects that a theme is gaining momentum, users need to be able to review the comments supporting that conclusion. Without this ability to verify the evidence, an emerging theme remains a claim that no one in the organization can confirm or challenge.

Finally, the index does not need to contain the complete history. The data lake can retain all customer feedback durably and at a relatively low cost, while OpenSearch can be limited to a rolling window that reflects actual search needs. This distinction has a direct impact on cost, since OpenSearch capacity is one of the more cost-sensitive components of the architecture.

Detecting changes over time

An insights engine becomes even more useful when it can identify how customer feedback is changing.

The architecture can aggregate themes by day, week or month and compare the current volume with a historical baseline. A sudden increase in packaging complaints after a product update could be surfaced for review. A new use case appearing across reviews and social media could be flagged before it becomes visible in quarterly research.

These signals can be calculated through scheduled Lambda functions or processing workflows coordinated by Step Functions. The engine could track the frequency of a theme, the number of products affected, the channels where it appears and whether the sentiment is becoming more negative.

It could also distinguish a true increase from a simple change in data volume. Ten complaints may be significant when based on 100 reviews, but less meaningful when based on 100,000.

The technical design therefore needs to preserve both the qualitative signal and the quantitative context.

Connecting qualitative feedback with sales data

Customer feedback becomes more useful when it can be examined alongside business performance. Retail sales reports stored in Amazon S3 can be normalized and associated with the same product, market and time dimensions used for reviews and support data. This creates a shared analytical model.

The organization can then explore whether an increase in customer questions coincides with a launch, a sales increase, a decline in repeat purchases or expansion into a new retail channel.

A product may have strong initial sales but a growing volume of support questions. Another may receive average ratings overall but perform particularly well in one region where customers describe an unexpected use case.

These relationships do not prove causation. They give teams a more focused place to investigate. Without a common data foundation, the feedback and sales information remain in separate systems and are often reviewed by separate teams.

Delivering the insights through Amazon Quick Suite

Amazon Quick Suite can provide the business intelligence layer for product, marketing, customer experience and innovation teams. The dashboards can expose a high-level view of emerging themes while allowing users to filter by product, geography, retail partner, channel or period.

A leadership dashboard might show the fastest-growing customer concerns, the products generating the most questions and the distribution of feedback across markets. On the other hand, a product team’s dashboard could compare recurring themes with ratings, returns or sales. A customer experience dashboard could show support volume by issue and identify questions appearing across several channels.

Adding human review where it matters

AWS generative AI outputs should not move directly into executive reporting or product decisions without validation. The architecture can include human review at several points.

Low-confidence classifications can be routed to a review queue. New or unusual themes can require approval before they are added to the official taxonomy. Analysts can correct incorrect product associations or topic labels. And all these corrections can be stored and used to evaluate future model performance.

A representative test dataset can help the engineering team compare prompts, models and classification approaches. The organization can measure whether the engine correctly identifies known themes, whether it produces valid structured outputs and whether it behaves consistently across languages and product categories.

This creates a practical evaluation process rather than relying on subjective impressions of whether a generated summary sounds convincing.

Securing the architecture

Consumer feedback may contain personal information, while retailer sales files may contain confidential commercial data. The AWS architecture should therefore apply security controls throughout the pipeline.

Data can be encrypted at rest using AWS Key Management Service and in transit using secure connections. AWS Identity and Access Management can limit access by role, workload and environment.

Amazon S3 bucket policies can restrict who can access raw, processed and curated data. Sensitive support records can be isolated from datasets intended for broader business reporting.

Processing can run inside a virtual private cloud when the architecture requires network isolation. Logs and metrics from Lambda, Step Functions and other services can be centralized in Amazon CloudWatch for monitoring and troubleshooting.

The model should receive only the information required for the task. Personal details can be removed before analysis, using Amazon Comprehend or Macie. Model outputs can be checked for sensitive content before being indexed or displayed.

These controls should be defined during architecture design rather than added after the insights engine is already in use.

Monitoring cost, performance and reliability

A production consumer insights engine also needs operational controls. Why? Because Lambda concurrency, Step Functions execution volumes, Bedrock model usage, OpenSearch capacity and Quick Suite activity can all affect cost and performance.

The architecture can use CloudWatch metrics and alarms to detect failed workflows, unusually high processing volumes, latency increases or indexing issues.

Model invocation quotas require particular attention because they are one of the most common constraints encountered in production. Amazon Bedrock applies request-per-minute and token-per-minute limits that vary by model and AWS Region. A Step Functions Distributed Map state can easily launch more concurrent calls than the applicable quota allows. The result is not a gradual slowdown, but throttling errors and failed workflows.

The concurrency of the Map state should therefore be capped according to the actual quota, and model calls should include a retry policy with exponential backoff. A quota increase is often required before production deployment, and the time needed for AWS to process that request should be included in the project schedule.

Model selection remains the main cost lever. Classifying feedback against a known taxonomy does not require the same level of capability as summarizing a conversation or interpreting an unexpected product use. A compact model can handle routine volume at a fraction of the cost, while a more capable model can be reserved for cases that genuinely require it.

For data sources that do not need to be updated immediately, Amazon Bedrock batch inference can process the same volume at a lower cost than on-demand inference. Conversely, when demand is sustained and predictable, Provisioned Throughput can make costs more stable.

Finally, each customer comment should be enriched only once. The analysis result is stored with the record so that changing a dashboard, adding a filter or asking a new business question never triggers another model call. Only a deliberate change to the prompt or taxonomy should require reprocessing, in which case the workflow can return to the raw data retained in Amazon S3.

Processing does not always need to happen in real time. Product reviews might be analyzed every few hours, while weekly retail reports can be processed when they arrive. Choosing the right frequency for each source can control costs without reducing the usefulness of the insights.

The system can also avoid reprocessing unchanged records. Content hashes, processing status fields and idempotent workflows help ensure that the same file or review is not analyzed repeatedly.

These engineering details determine whether the solution remains manageable as the number of products, markets and data sources grows.

Building AI on top of a reliable AWS foundation

The most visible component of a consumer insights engine may be the generative AI model, but the model is only one part of the system.

The value comes from the complete architecture: reliable ingestion, durable storage, repeatable processing, structured model outputs, searchable source evidence, business reporting, security and operational monitoring.

Unicorne helps organizations design and build these production-ready AI systems on AWS. Contact us today for more information.