Multi-Channel Content Management for large retailers

Authored by Andre Engberts and Arpit Jain, August 2013


3 4 6 9 14

Internal vs. External content sourcing and content aggregation Content usage scenarios
- Content types

Overview Multi-channel content processes
- Pre-authoring tasks - Authoring tasks - Publishing tasks

Transactional performance impact on the integration between a cms and a commerce engine Multi-channel synchronized content delivery High-level content pipeline architecture
- Content delivery integrates product and non-product content domains - The importance of content services in a multi-channel content architecture - The special case of content management for print - Matching delivery services options with channels

20 24 25


Illustrative scenario

Large retailers have unique challenges that come from the size of their catalog, the volume of sales transactions, the large number of shoppers and their dispersed geographical locations. Like other businesses that have gone digital, retailers have published their catalogs on site and mobile applications and most of them have implemented ecommerce. In addition to creating another selling channel, digital user experiences are also a way to drive customers to stores and provide a tool for product research, promotion and advertising. Wal-Mart, Target, Walgreens, Best Buy and many others have invested for years in their online channels. But the endeavor for these retailers (visit for a list of the top 100) has been different than small to medium size commerce sites such as REI, Williams-Sonoma or even AT& for mobile.

Large retailers have had to solve unique problems resulting from their size — how to integrate the enormous amount of content they publish with an ecommerce platform that is optimized for very high transaction volume, specifically.
This discussion note will cover both the complexity of content management within retail and the technology challenge of content management for both a multi-channel business environment and a highly scalable transactional platform. We will also discuss other architectural transformations related to the general business trends in retail. We will explain how the retail industry is converging towards a consistent vision for content management and publishing across both digital and traditional channels, and look for innovative applications of content that span guest experiences both online and at the store.


The need for channel diversification

Large retailers compete for a fixed population of consumers, knowing that the sum of offerings from each retailer is larger than what the market can consume as a whole. Winning the attention and purchasing transactions from the consumer is a challenge that requires retailers to be constantly top of mind when consumers are planning a purchase or about to make a purchase. Maintaining the constant attention of the guest and “being there” when a transaction can take place is what has led to a multi-channel diversification of interactions between retailers and the guest in the digital space. This diversification includes:

Multiple independent or combined offerings:
the main online store is complemented by registries for wedding or baby.

The physical world:
stores have in-store devices for viewing additional information while purchasing or to support flexible fulfillment. Anticipate that physical digital presence to extend beyond stores, to other showcase situations.

Competitors and partners:
retailers have created joint offers for guests with competitors like Target and Neiman Marcus, or with partners like Groupon.

Multiple brands:
large retailers have absorbed other brands or created their own (e.g., Neiman Marcus with Horchow and Last Call). Promoting brand individuality while maintaining a family look and consolidating content management infrastructure is a complex design problem from a visual design, content management and technical architecture standpoint.

Social media:
all large retailers are on Facebook, Twitter and YouTube.

Frequent refresh of offers:
on the site, mobile apps, microsites or weekly ads.

Multiple languages: Multiple form factors:
consumers can use a desktop/laptop as a high-speed, large format platform, a tablet for more mobility, and a smart phone that adds current location as the leading context. Wal-Mart is leading all retailers in providing ecommerce to multiple countries. Target is moving soon to Canada. The following table shows some examples of who is doing what in retail across multiple languages.





User experience in a multi-channel context

As a retailer diversifies its presence across channels, corresponding user experiences are unified to bundle the benefits of digital and traditional commerce on behalf of the customer. Complementary offerings like wedding and baby registries drive traffic to the online channel; having an in-store kiosk connects the digital and real-world experiences in a way that use of one drives more use of the other. To achieve cross-channel benefits, three high-level principles are followed:

1. Establishing a presence
that will provide guests with enough value and substance for rapid and long-term adoption.

2. Maintaining consistency of message

from one channel to the next to maintain overall brand impact.

3. Enabling continuity of experience
as guests conduct their research and transactions using a random combination of devices, at different times and in different locations.

Compelling content and content that is synchronized across channels, adapted and made available in the right context and at the right time are critical requirements for a multi-channel content architecture. Consistency and continuity drive more trust in the brand in the mind of the customer. This drives the impression that offerings and messages are well thought through and cared for.

Internal vs. external content sourcing and content aggregation
Content sources are not just internal but also external. The content management infrastructure stores, organizes and ranks content, but also moderates inputs for publishing in near-real time. That last aspect is one of the innovations taking place around content, where the content management infrastructure can aggregate and leverage content dynamically from a number of different “external” sources. Most CMS systems now provide a foundational capability to deliver this.

Marketers may need to leverage content from multiple sources and bring it all together in the context of a campaign or brand story. The ability to aggregate product and brand content from other sources in real time (whether these are conversations in the social space, or extended product data for product partner/reseller scenarios), tie it together semantically and then use it to drive use cases such as “related content” or “similar content” is another key differentiator. CMS and search technologies are leading the way here.

Content usage scenarios
In order to launch new experiences and marketing campaigns simultaneously across multiple channels, we want to reuse content, components, pages and, sometimes, entire sections of a site. For instance, many content components from the main site will find their way on the mobile web version, possibly in different form factors for tablet or mobile phone. Or, if you have an online gift registry, you will reuse most of the product browsing section of the original site. So synchronizing content that’s planned for different properties is important; however, not everything is reused from one experience to another and reuse is not necessarily hierarchical. In a multi-channel configuration, the graph of content sharing and dependency is a complex network, as illustrated above. mobile app Registry Site Main Site Microsite and campaign sites


Content types
In a network of digital properties, a variety of content types are being published and potentially shared. Content is grouped into two major areas that are managed separately but published jointly: product and non-product content. For product content, we find:

Product item information,
the core of the retailer’s digital data. Millions of Stock Keeping Units (SKUs) are potentially published, and product information is a collection of data properties, taxonomy information, images, copy text, videos, reviews, and much more.

Product categories, the data structure to group products. Categories can have content types attached to them such as
copy text, size charts, user guides, videos, images and more.

The process of creating and acquiring product information for very large amounts of items that are sourced from a variety of vendors requires a different process than web content management. Product information is also as data intensive as it is rich in content. A retailer will typically use PIM (Product Information Management) processes and technologies to manage that information. For non-product content, we find:

Components, which are composite content types that integrate text, images, data, videos and links to create digital ads,
offers and other page elements.

Non-product copy for marketing content that appears on category pages and other landing pages. Site templates that define the layout of pages.

Non-product images and animation or video assets for marketing purposes. Third-party syndicated copy content for stories around a content category and inspirational content.

A retailer will typically use CMS (Content Management System) processes and technologies to manage non-product information. In a multi-channel environment, the product and non-product content domains come together into a unified content delivery architecture to minimize the responsibility of each delivery end-point in assembling content from different sources. In the next few sections, we will focus on the key technology and process enablers for content in a retail environment, outlining solutions for the management of content in a scalable data, transactional and multi-channel environment.

Content management processes
The creation, composition and management of content for frequent site refreshes and for large amounts of product can take up to hundreds of workers focused on four major processes:

1. Digital planning and asset acquisition, the process of creating, buying or searching for assets given
the specification of a new user experience or a new campaign.

2. Digital asset ingestion and storage, how created or purchased assets are uploaded into a common
Digital Asset Management (DAM) system, associated with folders and metadata for use by content management workers, and to create user experiences within the CMS or other tools.

3. Web content management is where we create templates and assemble content into components or
pages. This is also where we run the review and approval workflow, version content and create multiple versions for different form factors.

4. Content publishing and delivery is the process of selecting the subset of the content that will be
deployed at a given time. The specifics of how that gets done depend on the delivery architecture, covered later.


These four processes include capabilities listed on the figure below:



Digital Planning and Asset Acquisition

Digital Asset Ingestion and Storage

Web Content Management

Content Publishing and Delivery

Media Asset Authoring Tools

Content Storage and Organization

Copy Content Authoring and Usability Template Management

Multi Channel Publishing Real time Content Delivery

WIP Workflow

Asset Ingestion

Distributed Process Management Integration with Digital Media Management

Video Management Process Integration with Digital Planning and PIM


Site Integration

Review Workflow

Multi-site management Personalization and Targeting

capability areas

Content life-cycle management Content metadata and Taxonomy management Syndicated content management Access Control Author Search


Syndicated content partner integration

End User Search Content Analytics Reporting

Let’s review next each of these processes in the context of multi-channel content management.

Multi-channel content processes
Assuming a multi-site content management process, where site “A” is the parent site and site “B” is the sub-site, using content from site “A,” we can look at the coordination of respective teams on three process segments:

1. Pre-authoring tasks 2. Authoring tasks 3. Publishing tasks

1. Pre-authoring tasks
For asset creation and ingestion, let’s assume we have multiple marketing campaigns that are going to focus on the same product set. In this case, planning is done upfront for a comprehensive acquisition of images, copy and videos, which are then tagged and organized to make it easy for all projects to identify common assets to reuse. This sounds trivial, but you would be surprised by how little reuse happens when you have hundreds of millions of assets and no effort for coordinating their reuse. Assets are expensive to produce or create from scratch. Reuse is a lot cheaper.

Asset Acquisition/ Creation

Digital Planning

Digital Asset ingestion and storage

Digital Application “A”

Team “A” performs the asset acquisition for both “A” and “B” on shared content

Both teams produce their own complete set of digital designs, with joint reviews for consistency

All Digital media assets are shared and accessible to both “A” and “B” and tagged for filtering and search

“B” uses content from “A”

Digital Application “B”

From a tooling standpoint, the coordination of distributed content management in pre-authoring tasks is mostly process. The digital planning process functions as team-independent activities with joint deliverable reviews triggered through workflow.


2. Authoring tasks
The authoring process, on the other hand, leverages from the collaboration and content sharing features of the content management tools. Reuse of content is planned by creating an initial “blueprint” of an experience—a content component, page fragment, entire page or sub-site. That blueprint is then duplicated as “synchronized copy” for use by a different channel. The copy is kept in sync, and is not a reference to a common object. The synchronization mechanism is such that it is up to the consumer of the copied content to decide when to use what may have been changed on the blueprint. Note that the CMS allows you to decide what you expose as content that can be reused and what you want to keep private to the site. Content access control lets you decide not to allow some sections of your site to become copied in another channel.

Digital Application “A”
Content only used by “A” Content made available to share with other apps

Digital Application “B”
Create content “synchronized copy”
Content reused from “A” Content used only by “B”

Create new content

Review and approve new content

Rollout new content

Content available and visible to site “B”

3. Publishing tasks
The publishing process is executed through a publishing workflow. Different digital properties will go through publishing independently from each other. Once content is created and made available to multiple channels, you want each site to remain in control of when they synchronize their updates and publishing actions. It can be simultaneous or deferred, or manually triggered. That all depends on what the channel management policies are.



Digital Application “A”

Content has been reviewed and approved for both sites independently from each other

Content is published to channels “A” and “B” independently from each other through separate workflows

“B” uses content from “A”

Digital Application “B”


End-point devices and delivery architecture

We have discussed content types and processes in a multi-channel context to understand the complexity of the management of large amounts of diverse content for large retailers in a multi-channel context. Let’s look now at the technical architecture for delivering content to application platforms for different channels. This architecture has to address both performance and multi-channel synchronization.

Transactional performance impact on the integration between a CMS and a commerce engine
Before we get into a CMS site delivery architecture overview, let’s go over why large retailers represent a special architecture case, due to the combination of high commerce transaction volume and high amounts of content to be displayed. Here are some examples of performance numbers around one US holiday period when purchasing is at a high:

• • • • • •

3,000+ transactions per second Response time ≤3 seconds 70K+ orders per hour 110K carts per hour 100% promotion on every customer shopping cart 2.3 million searches per hour

To achieve such performance, a few architectural principles are being followed:

• Caching at every level of the architecture. • Tight coupling of everything that is used for the rendition of the user experience. • Low-level code optimization.

Multi-channel synchronized content delivery
Once we diversify the delivery of content across multi-channel, we need to simplify how we build content-consuming applications and, in particular, how end-user applications assemble the content for display. This surfaces four main requirements:

1. Applications should not have to assemble content from multiple sources. Content is delivered as a whole at only two levels of granularity: pages and components. 2. Static versus dynamic content is transparent to the end-user application. 3. Content is served to all channels following a common framework. So, as you add a new channel, you don’t have to reengineer the content acquisition. The same content can be pushed simultaneously to all channels. 4. Content authoring is supported by an immediate, high fidelity content preview within the CMS.

High-level content pipeline architecture
In this section, we will assume that the CMS can be configured in both “fried” content publishing (the CMS being the live site platform) or “baked” content publishing (where the content is pushed asynchronously to the site delivery platform). Most leading content management platforms provide both capabilities. Content is delivered to the end-user device through oane of three methods:

1. Directly through the CMS, configured as a site delivery platform. The CMS engine is used as both a
content delivery platform and as an application server (behaving as a content portal). For instance, Adobe CQ is built on a fullservice Java application framework (Sling) that allows for managing content as well as building complete web applications. Open Text acquired Vignette as a portal that’s integrated with the content management backend. Autonomy has developed its own product, LiveSite, as a complementary offering to TeamSite—the “baked” offline version—and Sitecore and Ektron are tightly integrated with the .Net framework for web application development.

2. Using content services. Content can be delivered via content services for mobile native apps or mobile hybrid apps.
Here we are illustrating two types of services: real-time content services where the content is pulled by the delivery platform at the time it needs to be displayed and offline content services where the content is pulled by the delivery platform ahead of display time and is stored locally by the delivery platform. The difference between the two implementations is about performance. Real-time content services need to be scaled for run-time performance; offline content services do not.

3. Pushing “baked” content to an application delivery platform, such as an application server (e.g., IBM WCS,
Spring Framework, Oracle ATG). This approach enables the development of ecommerce applications that integrate a different framework for ecommerce page development with the CQ content framework. This configuration option is where we get the performance gain required for transactional performance—the ability to sustain high transaction volumes at a fast rate.


Page delivery Web or mobile site on enduser browser

Front-end caching servers

Real-time Content service

CMS authoring

Digital Application

Execute Publishing workflow

CMS application server Offline Content service

Fat client (e.g. Kiosk) or e-mail delivery (ExactTarget, Epsilon,...) Content deployment module (custom)

Non-CMS delivery platform integrates commerce framework with CMS-managed content Web or mobile site on enduser browser

Content delivery integrates product and non-product content domains
Ideally, product content and non-product content could come together in the CMS so that users can build and preview complete pages. A retailer’s volume of products, however, makes it impractical for authors to process the complete integrated content in the CMS. Doing so would require product information to be first pushed to the CMS and then pushed again to the delivery platform—a huge, redundant data flow. Instead, product information is moved directly to the delivery platform (the commerce product data catalog). The diagram on the following page shows how the commerce catalog or the corresponding service is used by the three delivery configurations above.


Native app on end-user device (phone, kiosk)

CMS publishing

Content services Web or mobile site on end-user browser

Commerce product catalog Catalog product data service

CMS Page delivery Native app on end-user device (phone, kiosk)

Product info

Accessed as data in the commerce platform

CMS Publishing

Commerce delivery platfrom (e.g. IBM WCS) integrates commerce framework with CMS-managed content

WCS Offline content push
WCS catalog

Web or mobile site on end-user browser

Product content integration with content services:
catalog via a service.

the content service layer accesses the product

Product content integration with CMS page delivery: pages being run on the CMS applications server
use components that list products retrieved from the commerce catalog through the content service layer.

Product content integration with the commerce delivery platform: if this is the case, the delivery
platform is exemplified with WCS and product information is retrieved locally from the catalog.


The importance of content services in a multi-channel content architecture
Content services play a critical role in the multi-channel content architecture, through two main functions:

1. Delivering content to server-side or client-side applications.

The content is delivered by the

service by default in either one of three formats: XML, JSON or HTML. Content delivered by services are page fragments. It would not make sense to use the content service option to deliver entire pages. For complete page delivery, “fried” or “baked” site configurations would be more effective.

2. Integrating product and non-product content for the consuming application. End-point
guest applications should not have to deal with the intricacies of managing and coordinating content from multiple sources. An end-point guest application should request content at the granularity of components, assuming that the complete component is delivered by a single service call, containing both product and non-product content.

The special case of content management for print
Content management and delivery for the print channel is a special case of the content architecture for two reasons:

1. “Pixels” in digital prints are of a much finer grain density than digital pixels on a computer, tablet or mobile device screen. A large monitor with fine resolution would still provide 2 to
3 times less pixel density than a 300 DPI print, itself an average-to-low print resolution.

2. The print color palette is different from the digital set of colors. Digital devices use the RGB
color scheme, based on three base colors and apply a color additive process to create all other colors (from pure black to other colors). Printers that are above desktop-companion grade use at least a four-color scheme, CMYK, and create additional colors using a subtracting process (from pure white to other colors). Fine, higher quality printing can use a six-color scheme, CMYKOG, which provides a much greater color gamut (the subset of the total color space that is reproduced).

The consequence of the first point is that layout composition for print cannot take place on a web-based interface, but requires a highly interactive client application (e.g., InDesign from Adobe) where zoom-in actions are better implemented. The consequence of the second point is that computer-based preview will be a low-fidelity preview from a color rendition standpoint. The CMS is still very valuable for managing printable content and deliverables, especially if there is a possibility of tight integration between the print document format and the CMS storage document representation. With Adobe CQ, for instance:

The Adobe toolset can integrate the InDesign server with CQ content management workflows, allowing print deliverables to follow authoring, review and publishing workflows using the same process management tools and processes as other channels.

• The initial composition of print designs can use the same asset creation tools and repositories as other channels during the digital planning process. • A low-fidelity preview of final designs is feasible to at least validate the general composition of deliverables.

Matching delivery services options with channels
Looking at the different channels listed earlier, and having identified integration options between CMS at the site platform, content services and content pushed to an application delivery platform, we can map one or more options with each channel:

CHANNEL Main site • • • Adjunct sites (e.g. a gift registry) where commerce is not a critical function Mobile web • • • • • • •

INTEGRATION OPTION Push content to the commerce application server. A template-publishing framework (e.g., FreeMarker) translates the page produced by the CMS to a page format that the commerce engine can process. Product information is accessed directly from the commerce catalog. Directly hosted by the CMS platform if that capability is available. Commerce functions, if any, are provided via commerce engine web services. Directly hosted by the CMS platform if that capability is available. Commerce functions, if any, are provided via commerce engine web services. Native apps are running within the device (e.g., iOS, Java Android apps, Java BlackBerry apps, Adobe AIR apps, Windows Mobile apps, Java or .NET client apps, PhoneGap apps). Native apps access dynamic content via content services (e.g., promotion and marketing components). Commerce data and content are integrated by content services so the mobile app does not have to assemble both. For in-store devices that render the UI through HTML, the same implementation strategy is used as for adjunct sites for large devices or mobile web for smaller devices (i.e., tablet size or below). For in-store devices that are implemented as native applications, content is provided via content services, similarly as for native apps. Create components that are published for a third party via content services. Create co-branded microsites using either the CMS hosting platform or an application delivery platform. Facebook page accesses content components via content services. See “The special case of content management for print.”

Native mobile apps

In-store devices — HTML compatible

In-store devices — native applications

Partner sites

• •

Social media Print

• •


The vision: the Content Hub
The potential use and management of content is rapidly expanding beyond the traditional capabilities of content management systems: • • • Content usage is across more channels and for new content types. Content management reaches out upstream to the digital planning process in order to streamline content management and planning. New applications of content are emerging (e.g., augmented reality, monetization).

This innovation related to content is captured by the concept of the Content Hub, which will bring new capabilities to the enterprise including: • • • • • Creation and delivery of campaigns within minutes of a public event, like the Oreo impromptu social media campaign during the Super Bowl blackout in New Orleans. Augmented reality via mobile devices to view additional content while browsing shelves at a store. Content for sale for DVM: create an ad inventory and sell it in real-time to a third party. Real-time content optimization: dynamically rank content based on popularity and display accordingly. Content aggregation with internal and third-party content: leveraging content networks to build “stories” around items being sold.

The Content Hub is an ecosystem of tools and technologies assembled to meet existing and future needs of a broad set of end users. Target industries for that vision include retail, manufacturing, consumer packaged goods and travel (hospitality in particular).

This vision is progressively being implemented by the top CMS vendors who already possess powerful, scalable platforms for content, asset management and delivery through both sites and services. Adding to that, these vendors are all addressing the coordination of content creation and organization for concurrent delivery methods and multiple languages. The next step is for vendors to develop an architecture where the platform packages content for emerging and future applications like the ones listed above. Recapitulating these points, we can put together a capability-based picture of what a multi-channel Content Hub would look like.


Planning MRM Campaign

Workflow Authoring

Dynamic Delivery





Asset Repository Promo PlanoGram Merchandising DRM





Data PIM – Guests – Analytics

In this picture, evolution and innovation will take place at the periphery of the diagram: • • • • Integrating methods for creating content and assets with creative tools, studios and external feeds. Adding content-related application capabilities for personalization, contextualization, monetization, content optimization and financial assessment of content performance. Linking content to data for personalization and monetization scenarios. Merging the delivery of content on traditional channels with the approach used today in digital channels.





Illustrative scenario
As an example of the future use of the Content Hub, let’s consider this example of a merchandiser launching a new line of summer clothing for teenagers. The merchandiser enlists the marketer to promote the new collection. As they and their teams work through each task, they use the suite of tools provided by the Content Hub.

Task Steps

Produce the digital assets to view the new collection online 1. 2. 3. 4. Suppliers upload their assets Merchandising team takes photography of samples Merchandising team uploads product assets in DAM Merchandising team solicits external content contribution from thirdparty syndicated content sources if applicable


PIM; DAM; Photography Studio; Vendor Product Portal

Task Steps

Create a seasonal launch campaign 1. 2. 3. 4. 5. 6. 7. 8. A campaign project is created and members of the marketing and merchandising teams are assigned to the project A campaign brief is produced Assets are retrieved from the DAM for use by the campaign creative team Additional photo shoot needs are identified and executed Campaign creative concepts are created, reviewed and approved The campaign content is produced for all the .com, mobile and email channels The campaign content is produced for print channels The campaign is deployed across all channels


Campaign management workflow; DAM; creative tool suite; photo studio; CMS authoring and workflow; InDesign server integrated with CMS authoring (integration only available if CMS is Adobe CQ); multi-channel delivery architecture

The campaign is rolled out a couple of days ahead of the product launch and analytics are collected on the campaign’s success. Immediately, data shows a strong interest by the product’s targeted audience.

Task Steps

Monitor campaign success across all channels using a fine-grain analysis at content level 1. 2. Collect click data on campaign assets on site, mobile and email Make user experience adjustments through A/B testing


Analytics integrated with site, mobile and email; content tagging; A/B testing infrastructure

The merchandiser and marketer decide to immediately capitalize on the opportunity and prepare a social media campaign to follow the product launch on the sale of accessories. The social media plan is to share with friends the accessories bought together with an item from the collection. The action of sharing wins the participant a coupon for an online purchase of a collection’s item. Data associated with the popularity of accessories leads to a higher ranking of the display of the corresponding content and to the rapid creation of new digital promotions and ads that are published on other sites.

Task Steps

Rapidly develop a social media application 1. 2. Build social media app with content services for user to view both collection items they bought and related accessories Collect social media interaction data


Content services; social media application framework (not part of Content Hub); analytics

As shoppers walk through stores and come close to the collection being promoted, the social media interaction comes up on their mobile phones. Comments on the items they are standing in front of are being shown as a reality augmentation. Accessories popular with this item are also listed. If these accessories are available at the store, their locations are indicated.

Task Steps Tools

Integrate a barcode reader with the mobile social media shopper app 1. Retrieve social media interaction data and content with product barcode

Content services; social media application framework (not part of Content Hub); barcode reader API

From a DVM standpoint, placement for ads for accessories that can be sold through other retailers have their prices adjusted accordingly.

Task Steps Tools

Update ad placement strategy 1. 2. ollect content click data C Adjust ad expected click ratio

Content services; content monetization framework



Content, its applications and transactional capabilities are the pillars of a digital commerce experience for large retailers. The ability to deliver them in a multi-channel environment brings ubiquity and continuity of experience across user platforms—thereby building trust and driving conversion. The lines are blurring between the digital and physical, and we can soon expect the physical store experience to be augmented with virtual reality that involves social interactions. This new perspective drives new content and experience architectures for large retailers. Working hand in hand with technology, content management processes are transforming in order to focus on the channel transparency of the message to the customer—with faster and more streamlined publishing as well. Leading CMS vendors are aware of these trends and are acquiring and integrating products that focus on the next generation user experience for commerce. How these tools are integrated is the current challenge for large retailers today.

about the authors
Arpit Jain, Senior Manager Program Management, SapientNitro
Arpit has been with SapientNitro for over 7 years and has been involved on multiple engagements across retail, energy and telecom industries. He has about 10 years of industry experience around retail ecommerce, program management and quality assurance domains. Over the last several years, he has been leading the delivery/future state of Target’s online platform experience and also driving the future state of content management for Target’s multi-channel organization spanning across technology and business. Arpit holds a Mechanical Engineering Degree from Delhi University, India.

Andre Engberts, Technology Director, SapientNitro
Andre has been with SapientNitro since April 2012 and has been leading a technology team at a large retailer since then. Prior to working with SapientNitro, Andre had been in the field of Digital Marketing Technology for 12 years, working with clients such as AT&T, Dell, Humana and Samsung among others. Andre’s experience spans both web and mobile technologies with a recent focus on eCommerce, content management systems and content strategies. Andre has also provided consulting on process redesign and enterprise-level technology direction. Andre holds an Engineering degree in Electrical Engineering from the Ecole Superieure d’Electricite, Paris, France and an MS and PhD in Computer Engineering from the Illinois Institute of Technology.


Sign up to vote on this title
UsefulNot useful