Some of the most impressive marketing systems I’ve seen have been developed for mobile phone marketing, especially for companies that sell prepaid phones. I don’t know why: probably some combination of intense competition, easy switching when customers have no subscription, location as a clear indicator of varying needs, immediately measurable financial impact, and lack of legacy constraints in a new industry. Many of these systems have developed outside the United States, since prepaid phones have a smaller market share here than elsewhere.
Flytxt is a good example. Founded in India in 2008, its original clients were South Asian and African companies whose primary product was text messaging. The company has since expanded in all directions: it has clients in 50+ countries including South America and Europe plus a beachhead in the U.S.; its phone clients sell many more products than text; it has a smattering of clients in financial services and manufacturing; and it has corporate offices in Dubai and headquarters in the Netherlands.
The product itself is equally sprawling. Its architecture spans what I usually call the data, decision, and delivery layers, although Flytxt uses different language. The foundation (data) layer includes data ingestion from batch and real-time sources with support for structured, semi-structured and unstructured data, data preparation including deterministic identity stitching, and a Hadoop-based data store. The intelligence (decision) layer provides rules, recommendations, visualization, packaged and custom analytics, and reporting. The application (delivery) layer supports inbound and outbound campaigns, a mobile app, and an ad server for clients who want to sell ads on their own Web sites.
To be a little more precise, Flytxt’s application layer uses API connectors to send messages to actual delivery systems such as Web sites and email engines. Most enterprises prefer this approach because they have sophisticated delivery systems in place and use them for other purposes beyond marketing messaging.
And while we’re being precise: Flytxt isn’t a Customer Data Platform because it doesn’t give external systems direct access its unified customer data store. But it does provide APIs to extract reports and selected data elements and can build custom connectors as needed. So it could probably pass as a CDP for most purposes.
Given the breadth of Flytxt’s features, you might expect the individual features to be relatively shallow. Not so. The system has advanced capabilities throughout. Examples include anonymizing personally identifiable information before sharing customer data; multiple language versions attached to the one offer; rewards linked to offers; contact frequency limits by channel across all campaigns; rule- and machine learning-based recommendations; six standard predictive models plus tools to create custom models; automated control groups in outbound campaigns; real-time event-based program triggers; and a mobile app with customer support, account management, chat, personalization, and transaction capabilities. The roadmap is also impressive, including automated segment discovery and autonomous agents to find next best actions.
What particularly caught my eye was Flytxt’s ability to integrate context with offer selection. Real-time programs are connected to touchpoints such as Web site. When a customer appears, Flytxtidentifies the customer, looks up her history and segment data, and infers intent from the current behavior and context (such as location), and returns the appropriate offer for the current situation. The offer and message can be further personalized based on customer data.
This ability to tailor behaviors to the current context is critical for reacting to customer needs and taking advantage of the opportunities those needs create. It’s not unique to Flytxt but it's also not standard among customer interaction systems. Many systems could probably achieve similar outcomes by applying standard offer arbitration techniques, which generally define the available offers in a particular situation and pick the highest value offer for the current customer. But explicitly relating the choice to context strikes me as an improvement because it clarifies what marketers should consider in setting up their rules.
On the other hand, Flytxt doesn't place its programs or offers into the larger context of the customer lifecycle. This means its up to marketers to manually ensure that messages reflect consistent treatment based on the customer's lifecycle stage. Then again, few other products do this either...although I believe that will change fairly soon as the need for the lifecycle framework becomes more apparent.
Flytxt currently has more than 100 enterprise clients. Pricing is based on number of customers, revenue-gain sharing, or both. Starting price is around $300,000 per year and can reach several million dollars.
Showing posts with label lifecycle analysis. Show all posts
Showing posts with label lifecycle analysis. Show all posts
Sunday, October 29, 2017
Wednesday, June 08, 2011
Coremetrics Offers a Foggy View of Lifecycle Analysis
I stumbled over an Adexchanger interview yesterday with John Squire, the Chief Strategy Officer of IBM Coremetrics. It first caught my eye because the headline read “IBM’s Vision for the Marketer”, which is always a topic of interest. Then I noticed it was touting new reporting feature called Coremetrics Lifecycle, which the company describes as “the industry’s first application geared to enable online marketers to track and understand how customers progress through long-term conversion lifecycles.”
This was intriguing. On one hand, I’ve seen plenty of systems that track customers through the buying process, including Eloqua, Marketo, Leadformix, Clear Saleing, C3 Metrics, and Encore Media Metrics. So the claim to be first is questionable. But, on the other hand, seeing another vendor offer this sort of analysis reinforces the importance of the concept.
But a closer look at Lifecycle itself was disappointing. The product does allow tracking of individual Web site visitors over time, which is the foundation of lifecycle analysis. But, in my opinion, a lifecycle tracking system reports on movement of customers across stages within the lifecycle. That is, it shows conversions from one stage to the next. This implies reports that show the previous stages of customers who enter a new stage (“where they came from”), and show the destinations of customers who leave a stage (“where they went”). These are typically represented as a matrix showing all combinations of previous and current stages, or a flow chart that highlights the most common before-and-after pairs.
Lifecycle does none of this. Rather, it lets users define any number of segmentation schemes and count the number of customers in each segment. It does report how many customers entered each segment during a specified time period, but not where they came from. In fact, there is no requirement for a logical progression from one segment to the next, which to me is what a lifecycle implies.
Lifecycle has some other useful features. It can report on the most common marketing treatments received by people who moved into a segment, giving some insight into treatment effectiveness. It calculates the average number of days and Web sessions that customers spend in a segment, which is a limited velocity measure. It also lets users select segment members and send them messages through Coremetrics’ products for email, display ad retargeting, and Web site personalization, although it's not clear the process can be automated.
But a proper lifecycle analysis tool would go much further. It would calculate the end-to-end completion rates, show the drop-off from one stage to the next, estimate the incremental impact of specific treatments, project future segment counts, and show changes in these measures over time. So while I’m pleased that Coremetrics is promoting the concept of lifecycle analysis, I’m disappointed that its product doesn’t deliver a real lifecycle measurement solution.
Addendum - June 19, 2011
After the original post and IBM's comment on it, I reviewed the Lifecycle product with the Coremetrics team. This uncovered no substantive errors in the original post, although a couple of points could have been stated more clearly.
- the system supports two types of lifecycles, one requiring that customers progress through the stages in sequence and one that does not. Users specify the type when they set up a new lifecycle. In both cases, the stages are defined by selection rules created by the user.
- there is a limit of six stages per lifeycle.
- for sequential lifecycles, the system will warn the user if the selection rules are not inherently sequential. (An inherently sequential rule might be based on the number of purchases made; you can't make three purchases without having previously made two. Other stage definitions, such as downloading a white paper or leaving a comment, might come in any order and, therefore, are not inherently sequential.)
- in a sequential lifecycle, the system will not allow customers to advance outside of sequence even if the definitions would allow it. Nor does it report on customers who would qualify for a later stage but cannot reach it because they didn't qualify for a previous one.
- the system's primary report shows the number of customers within each stage during a specified date range. Think of this as an inventory. A "Migrator" report shows how many customers entered their current stage during the report period: for example, there were 500 customers in stage 3, of whom 200 first entered stage 3 during this period. This gives some sense of movement, but it's not the classic funnel analysis showing the percentage of customers in each stage who eventually move to the next stage.
- users can run the standard reports against "segments", which could be defined as anything including a cohort of customers who entered the system during a specified time period. A Lifecycle inventory report for such a cohort would show how many customers reached each stage and got no further. This is the information needed to build a classic funnel analysis, although users would have to extract the data and manipulate it to produce an actual funnel report. This would be done outside of Coremetrics, because there is no end-user report writer.
- reports show the average number of days and Web sessions it takes customers to reach each stage (i.e., since they first entered the system), not the number of days and sessions spent in each stage, as I wrote originally.
- users do have the option to create a recurring process that automatically selects customers in a particular stage and sends them an email or other message. The system could apply a few rules to this process, such as eliminating people who had been selected previously. But more sophisticated controls would be handled outside of Coremetrics, in the message delivery system.
- the system can profile customers in each stage against many attributes (products purchased, geography, social network membership, etc.) in addition to marketing contents received. But, as I wrote originally, the reporting only shows the percentage of customers in each stage who match a particular attribute: this is far from measuring influence, for reasons I'll explain in a future post.
- we confirmed that the system doesn't do projections of future inventory counts, report on out-of-sequence customer movements, or allow customers to migrate backwards into lower-ranked stages (as might happen if stages were based on recency or ratios).
I'm happy to have clarified these matters but none of this changes my original assessment: Lifecycle is a useful product that falls far short of serious life stage analysis.
This was intriguing. On one hand, I’ve seen plenty of systems that track customers through the buying process, including Eloqua, Marketo, Leadformix, Clear Saleing, C3 Metrics, and Encore Media Metrics. So the claim to be first is questionable. But, on the other hand, seeing another vendor offer this sort of analysis reinforces the importance of the concept.
But a closer look at Lifecycle itself was disappointing. The product does allow tracking of individual Web site visitors over time, which is the foundation of lifecycle analysis. But, in my opinion, a lifecycle tracking system reports on movement of customers across stages within the lifecycle. That is, it shows conversions from one stage to the next. This implies reports that show the previous stages of customers who enter a new stage (“where they came from”), and show the destinations of customers who leave a stage (“where they went”). These are typically represented as a matrix showing all combinations of previous and current stages, or a flow chart that highlights the most common before-and-after pairs.
Lifecycle does none of this. Rather, it lets users define any number of segmentation schemes and count the number of customers in each segment. It does report how many customers entered each segment during a specified time period, but not where they came from. In fact, there is no requirement for a logical progression from one segment to the next, which to me is what a lifecycle implies.
Lifecycle has some other useful features. It can report on the most common marketing treatments received by people who moved into a segment, giving some insight into treatment effectiveness. It calculates the average number of days and Web sessions that customers spend in a segment, which is a limited velocity measure. It also lets users select segment members and send them messages through Coremetrics’ products for email, display ad retargeting, and Web site personalization, although it's not clear the process can be automated.
But a proper lifecycle analysis tool would go much further. It would calculate the end-to-end completion rates, show the drop-off from one stage to the next, estimate the incremental impact of specific treatments, project future segment counts, and show changes in these measures over time. So while I’m pleased that Coremetrics is promoting the concept of lifecycle analysis, I’m disappointed that its product doesn’t deliver a real lifecycle measurement solution.
Addendum - June 19, 2011
After the original post and IBM's comment on it, I reviewed the Lifecycle product with the Coremetrics team. This uncovered no substantive errors in the original post, although a couple of points could have been stated more clearly.
- the system supports two types of lifecycles, one requiring that customers progress through the stages in sequence and one that does not. Users specify the type when they set up a new lifecycle. In both cases, the stages are defined by selection rules created by the user.
- there is a limit of six stages per lifeycle.
- for sequential lifecycles, the system will warn the user if the selection rules are not inherently sequential. (An inherently sequential rule might be based on the number of purchases made; you can't make three purchases without having previously made two. Other stage definitions, such as downloading a white paper or leaving a comment, might come in any order and, therefore, are not inherently sequential.)
- in a sequential lifecycle, the system will not allow customers to advance outside of sequence even if the definitions would allow it. Nor does it report on customers who would qualify for a later stage but cannot reach it because they didn't qualify for a previous one.
- the system's primary report shows the number of customers within each stage during a specified date range. Think of this as an inventory. A "Migrator" report shows how many customers entered their current stage during the report period: for example, there were 500 customers in stage 3, of whom 200 first entered stage 3 during this period. This gives some sense of movement, but it's not the classic funnel analysis showing the percentage of customers in each stage who eventually move to the next stage.
- users can run the standard reports against "segments", which could be defined as anything including a cohort of customers who entered the system during a specified time period. A Lifecycle inventory report for such a cohort would show how many customers reached each stage and got no further. This is the information needed to build a classic funnel analysis, although users would have to extract the data and manipulate it to produce an actual funnel report. This would be done outside of Coremetrics, because there is no end-user report writer.
- reports show the average number of days and Web sessions it takes customers to reach each stage (i.e., since they first entered the system), not the number of days and sessions spent in each stage, as I wrote originally.
- users do have the option to create a recurring process that automatically selects customers in a particular stage and sends them an email or other message. The system could apply a few rules to this process, such as eliminating people who had been selected previously. But more sophisticated controls would be handled outside of Coremetrics, in the message delivery system.
- the system can profile customers in each stage against many attributes (products purchased, geography, social network membership, etc.) in addition to marketing contents received. But, as I wrote originally, the reporting only shows the percentage of customers in each stage who match a particular attribute: this is far from measuring influence, for reasons I'll explain in a future post.
- we confirmed that the system doesn't do projections of future inventory counts, report on out-of-sequence customer movements, or allow customers to migrate backwards into lower-ranked stages (as might happen if stages were based on recency or ratios).
I'm happy to have clarified these matters but none of this changes my original assessment: Lifecycle is a useful product that falls far short of serious life stage analysis.
Subscribe to:
Posts (Atom)
