Recherche avancée

Sur d’autres sites (6328)

• 10 Customer Segments Examples and Their Benefits

  9 mai 2024, par Erin

  Now that companies can segment buyers, the days of mass marketing are behind us. Customer segmentation offers various benefits for marketing, content creation, sales, analytics teams and more. Without customer segmentation, your personalised marketing efforts may fall flat. 

  According to the Twilio 2023 state of personalisation report, 69% of business leaders have increased their investment in personalisation. There’s a key reason for this — customer retention and loyalty directly benefit from personalisation. In fact, 62% of businesses have cited improved customer retention due to personalisation efforts. The numbers don’t lie. 

  Keep reading to learn how customer segments can help you fine-tune your personalised marketing campaigns. This article will give you a better understanding of customer segmentation and real-world customer segment examples. You’ll leave with the knowledge to empower your marketing strategies with effective customer segmentation. 

  What are customer segments ?

  Customer segments are distinct groups of people or organisations with similar characteristics, needs and behaviours. Like different species of plants in a garden, each customer segment has specific needs and care requirements. Customer segments are useful for tailoring personalised marketing campaigns for specific groups.

  Personalised marketing has been shown to have significant benefits — with 56% of consumers saying that a personalised experience would make them become repeat buyers. 

  Successful marketing teams typically focus on these types of customer segmentation :

  

  1. Geographic segmentation : groups buyers based on their physical location — country, city, region or climate — and language.
  2. Purchase history segmentation : categorises buyers based on their purchasing habits — how often they make purchases — and allows brands to distinguish between frequent, occasional and one-time buyers. 
  3. Product-based segmentation : groups buyers according to the products they prefer or end up purchasing. 
  4. Customer lifecycle segmentation : segments buyers based on where they are in the customer journey. Examples include new, repeat and lapsed buyers. This segmentation category is also useful for understanding the behaviour of loyal buyers and those at risk of churning. 
  5. Technographic segmentation : focuses on buyers’ technology preferences, including device type, browser type, and operating system. 
  6. Channel preference segmentation : helps us understand why buyers prefer to purchase via specific channels — whether online channels, physical stores or a combination of both. 
  7. Value-based segmentation : categorises buyers based on their average purchase value and sensitivity to pricing, for example. This type of segmentation can provide insights into the behaviours of price-conscious buyers and those willing to pay premium prices. 

  Customer segmentation vs. market segmentation

  Customer segmentation and market segmentation are related concepts, but they refer to different aspects of the segmentation process in marketing. 

  Market segmentation is the broader process of dividing the overall market into homogeneous groups. Market segmentation helps marketers identify different groups based on their characteristics or needs. These market segments make it easier for businesses to connect with new buyers by offering relevant products or new features. 

  On the other hand, customer segmentation is used to help you dig deep into the behaviour and preferences of your current customer base. Marketers use customer segmentation insights to create buyer personas. Buyer personas are essential for ensuring your personalised marketing efforts are relevant to the target audience. 

  10 customer segments examples

  Now that you better understand different customer segmentation categories, we’ll provide real-world examples of how customer segmentation can be applied. You’ll be able to draw a direct connection between the segmentation category or categories each example falls under.

  One thing to note is that you’ll want to consider privacy and compliance when you are considering collecting and analysing types of data such as gender, age, income level, profession or personal interests. Instead, you can focus on these privacy-friendly, ethical customer segmentation types :

  1. Geographic location (category : geographic segmentation)

  The North Face is an outdoor apparel and equipment company that relies on geographic segmentation to tailor its products toward buyers in specific regions and climates. 

  For instance, they’ll send targeted advertisements for insulated jackets and snow gear to buyers in colder climates. For folks in seasonal climates, The North Face may send personalised ads for snow gear in winter and ads for hiking or swimming gear in summer. 

  The North Face could also use geographic segmentation to determine buyers’ needs based on location. They can use this information to send targeted ads to specific customer segments during peak ski months to maximise profits.

  2. Preferred language (category : geographic segmentation)

  Your marketing approach will likely differ based on where your customers are and the language they speak. So, with that in mind, language may be another crucial variable you can introduce when identifying your target customers. 

  Language-based segmentation becomes even more important when one of your main business objectives is to expand into new markets and target international customers — especially now that global reach is made possible through digital channels. 

  Coca-Cola’s “Share a Coke” is a multi-national campaign with personalised cans and bottles featuring popular names from countries around the globe. It’s just one example of targeting customers based on language.

  3. Repeat users and loyal customers (category : customer lifecycle segmentation)

  Sephora, a large beauty supply company, is well-known for its Beauty Insider loyalty program. 

  It segments customers based on their purchase history and preferences and rewards their loyalty with gifts, discounts, exclusive offers and free samples. And since customers receive personalised product recommendations and other perks, it incentivises them to remain members of the Beauty Insider program — adding a boost to customer loyalty.

  By creating a memorable customer experience for this segment of their customer base, staying on top of beauty trends and listening to feedback, Sephora is able to keep buyers coming back.

  

  4. New customers (category : customer lifecycle segmentation)

  Subscription services use customer lifecycle segmentation to offer special promotions and trials for new customers. 

  HBO Max is a great example of a real company that excels at this strategy : 

  They offer 40% savings on an annual ad-free plan, which targets new customers who may be apprehensive about the added monthly cost of a recurring subscription.

  This marketing strategy prioritises fostering long-term customer relationships with new buyers to avoid high churn rates. 

  5. Cart abandonment (category : purchase history segmentation)

  With a rate of 85% among US-based mobile users, cart abandonment is a huge issue for ecommerce businesses. One way to deal with this is to segment inactive customers and cart abandoners — those who showed interest by adding products to their cart but haven’t converted yet — and send targeted emails to remind them about their abandoned carts.

  E-commerce companies like Ipsy, for example, track users who have added items to their cart but haven’t followed through on the purchase. The company’s messaging often contains incentives — like free shipping or a limited-time discount — to encourage passive users to return to their carts. 

  Research has found that cart abandonment emails with a coupon code have a high 44.37% average open rate. 

  6. Website activity (category : technographic segmentation)

  It’s also possible to segment customers based on website activity. Now, keep in mind that this is a relatively broad approach ; it covers every interaction that may occur while the customer is browsing your website. As such, it leaves room for many different types of segmentation. 

  For instance, you can segment your audience based on the pages they visited, the elements they interacted with — like CTAs and forms — how long they stayed on each page and whether they added products to their cart. 

  Matomo’s Event Tracking can provide additional context to each website visit and tell you more about the specific interactions that occur, making it particularly useful for segmenting customers based on how they spend their time on your website. 

  Try Matomo for Free

  Get the web insights you need, while respecting user privacy.

  Start for free

  No credit card required

  Amazon segments its customers based on browsing behaviour — recently viewed products and categories, among other things — which, in turn, allows them to improve the customer’s experience and drive sales.

  7. Traffic source (category : channel segmentation) 

  You can also segment your audience based on traffic sources. For example, you can determine if your website visitors arrived through Google and other search engines, email newsletters, social media platforms or referrals. 

  In other words, you’ll create specific audience segments based on the original source. Matomo’s Acquisition feature can provide insights into five different types of traffic sources — search engines, social media, external websites, direct traffic and campaigns — to help you understand how users enter your website.

  You may find that most visitors arrive at your website through social media ads or predominantly discover your brand through search engines. Either way, by learning where they’re coming from, you’ll be able to determine which conversion paths you should prioritise and optimise further. 

  8. Device type (category : technographic segmentation)

  Device type is customer segmentation based on the devices that potential customers may use to access your website and view your content. 

  It’s worth noting that, on a global level, most people (96%) use mobile devices — primarily smartphones — for internet access. So, there’s a high chance that most of your website visitors are coming from mobile devices, too. 

  However, it’s best not to assume anything. Matomo can detect the operating system and the type of device — desktop, mobile device, tablet, console or TV, for example. 

  By introducing the device type variable into your customer segmentation efforts, you’ll be able to determine if there’s a preference for mobile or desktop devices. In return, you’ll have a better idea of how to optimise your website — and whether you should consider developing an app to meet the needs of mobile users.

  Try Matomo for Free

  Get the web insights you need, while respecting user privacy.

  Start for free

  No credit card required

  9. Browser type (category : technographic segmentation)

  Besides devices, another type of segmentation that belongs to the technographic category and can provide valuable insights is browser-related. In this case, you’re tracking the internet browser your customers use. 

  Many browser types are available — including Google Chrome, Microsoft Edge, Safari, Firefox and Brave — and each may display your website and other content differently. 

  So, keeping track of your customers’ preferred choices is important. Otherwise, you won’t be able to fully understand their online experience — or ensure that these browsers are displaying your content properly. 

  

  10. Ecommerce activity (category : purchase history, value based, channel or product based segmentation) 

  Similar to website activity, looking at ecommerce activity can tell your sales teams more about which pages the customer has seen and how they have interacted with them. 

  With Matomo’s Ecommerce Tracking, you’ll be able to keep an eye on customers’ on-site behaviours, conversion rates, cart abandonment, purchased products and transaction data — including total revenue and average order value.

  Considering that the focus is on sales channels — such as your online store — this approach to customer segmentation can help you improve the sales experience and increase profitability. 

  Start implementing these customer segments examples

  With ever-evolving demographics and rapid technological advancements, customer segmentation is increasingly complex. The tips and real-world examples in this article break down and simplify customer segmentation so that you can adapt to your customer base. 

  Customer segmentation lays the groundwork for your personalised marketing campaigns to take off. By understanding your users better, you can effectively tailor each campaign to different segments. 

  If you’re ready to see how Matomo can elevate your personalised marketing campaigns, try it for free for 21 days. No credit card required.

  Try Matomo for Free

  21 day free trial. No credit card required.

  
  

  Your email address
  

  Your website address
  

  Your Analytics subdomain will be .matomo.cloud (change)

  Choose your analytics subdomain
  

  .matomo.cloud

  I accept the terms and conditions and data processing agreement (DPA)

  
  Your information will be used to create an account on our cloud service. For more information please consult our privacy policy.
  
  
  

  Start improving your websites now

  

• WebVTT as a W3C Recommendation

  1er janvier 2014, par silvia

  Three weeks ago I attended TPAC, the annual meeting of W3C Working Groups. One of the meetings was of the Timed Text Working Group (TT-WG), that has been specifying TTML, the Timed Text Markup Language. It is now proposed that WebVTT be also standardised through the same Working Group.

  How did that happen, you may ask, in particular since WebVTT and TTML have in the past been portrayed as rival caption formats ? How will the WebVTT spec that is currently under development in the Text Track Community Group (TT-CG) move through a Working Group process ?

  I’ll explain first why there is a need for WebVTT to become a W3C Recommendation, and then how this is proposed to be part of the Timed Text Working Group deliverables, and finally how I can see this working between the TT-CG and the TT-WG.

  Advantages of a W3C Recommendation

  TTML is a XML-based markup format for captions developed during the time that XML was all the hotness. It has become a W3C standard (a so-called “Recommendation”) despite not having been implemented in any browsers (if you ask me : that’s actually a flaw of the W3C standardisation process : it requires only two interoperable implementations of any kind – and that could be anyone’s JavaScript library or Flash demonstrator – it doesn’t actually require browser implementations. But I digress…). To be fair, a subpart of TTML is by now implemented in Internet Explorer, but all the other major browsers have thus far rejected proposals of implementation.

  Because of its Recommendation status, TTML has become the basis for several other caption standards that other SDOs have picked : the SMPTE’s SMPTE-TT format, the EBU’s EBU-TT format, and the DASH Industry Forum’s use of SMPTE-TT. SMPTE-TT has also become the “safe harbour” format for the US legislation on captioning as decided by the FCC. (Note that the FCC requirements for captions on the Web are actually based on a list of features rather than requiring a specific format. But that will be the topic of a different blog post…)

  WebVTT is much younger than TTML. TTML was developed as an interchange format among caption authoring systems. WebVTT was built for rendering in Web browsers and with HTML5 in mind. It meets the requirements of the <track> element and supports more than just captions/subtitles. WebVTT is popular with browser developers and has already been implemented in all major browsers (Firefox Nightly is the last to implement it – all others have support already released).

  As we can see and as has been proven by the HTML spec and multiple other specs : browsers don’t wait for specifications to have W3C Recommendation status before they implement them. Nor do they really care about the status of a spec – what they care about is whether a spec makes sense for the Web developer and user communities and whether it fits in the Web platform. WebVTT has obviously achieved this status, even with an evolving spec. (Note that the spec tries very hard not to break backwards compatibility, thus all past implementations will at least be compatible with the more basic features of the spec.)

  Given that Web browsers don’t need WebVTT to become a W3C standard, why then should we spend effort in moving the spec through the W3C process to become a W3C Recommendation ?

  The modern Web is now much bigger than just Web browsers. Web specifications are being used in all kinds of devices including TV set-top boxes, phone and tablet apps, and even unexpected devices such as white goods. Videos are increasingly omnipresent thus exposing deaf and hard-of-hearing users to ever-growing challenges in interacting with content on diverse devices. Some of these devices will not use auto-updating software but fixed versions so can’t easily adapt to new features. Thus, caption producers (both commercial and community) need to be able to author captions (and other video accessibility content as defined by the HTML5 element) towards a feature set that is clearly defined to be supported by such non-updating devices.

  Understandably, device vendors in this space have a need to build their technology on standardised specifications. SDOs for such device technologies like to reference fixed specifications so the feature set is not continually updating. To reference WebVTT, they could use a snapshot of the specification at any time and reference that, but that’s not how SDOs work. They prefer referencing an officially sanctioned and tested version of a specification – for a W3C specification that means creating a W3C Recommendation of the WebVTT spec.

  Taking WebVTT on a W3C recommendation track is actually advantageous for browsers, too, because a test suite will have to be developed that proves that features are implemented in an interoperable manner. In summary, I can see the advantages and personally support the effort to take WebVTT through to a W3C Recommendation.

  Choice of Working Group

  FAIK this is the first time that a specification developed in a Community Group is being moved into the recommendation track. This is something that has been expected when the W3C created CGs, but not something that has an established process yet.

  The first question of course is which WG would take it through to Recommendation ? Would we create a new Working Group or find an existing one to move the specification through ? Since WGs involve a lot of overhead, the preference was to add WebVTT to the charter of an existing WG. The two obvious candidates were the HTML WG and the TT-WG – the first because it’s where WebVTT originated and the latter because it’s the closest thematically.

  Adding a deliverable to a WG is a major undertaking. The TT-WG is currently in the process of re-chartering and thus a suggestion was made to add WebVTT to the milestones of this WG. TBH that was not my first choice. Since I’m already an editor in the HTML WG and WebVTT is very closely related to HTML and can be tested extensively as part of HTML, I preferred the HTML WG. However, adding WebVTT to the TT-WG has some advantages, too.

  Since TTML is an exchange format, lots of captions that will be created (at least professionally) will be in TTML and TTML-related formats. It makes sense to create a mapping from TTML to WebVTT for rendering in browsers. The expertise of both, TTML and WebVTT experts is required to develop a good mapping – as has been shown when we developed the mapping from CEA608/708 to WebVTT. Also, captioning experts are already in the TT-WG, so it helps to get a second set of eyes onto WebVTT.

  A disadvantage of moving a specification out of a CG into a WG is, however, that you potentially lose a lot of the expertise that is already involved in the development of the spec. People don’t easily re-subscribe to additional mailing lists or want the additional complexity of involving another community (see e.g. this email).

  So, a good process needs to be developed to allow everyone to contribute to the spec in the best way possible without requiring duplicate work. How can we do that ?

  The forthcoming process

  At TPAC the TT-WG discussed for several hours what the next steps are in taking WebVTT through the TT-WG to recommendation status (agenda with slides). I won’t bore you with the different views – if you are keen, you can read the minutes.

  What I came away with is the following process :

  1. Fix a few more bugs in the CG until we’re happy with the feature set in the CG. This should match the feature set that we realistically expect devices to implement for a first version of the WebVTT spec.
  2. Make a FSA (Final Specification Agreement) in the CG to create a stable reference and a clean IPR position.
  3. Assuming that the TT-WG’s charter has been approved with WebVTT as a milestone, we would next bring the FSA specification into the TT-WG as FPWD (First Public Working Draft) and immediately do a Last Call which effectively freezes the feature set (this is possible because there has already been wide community review of the WebVTT spec) ; in parallel, the CG can continue to develop the next version of the WebVTT spec with new features (just like it is happening with the HTML5 and HTML5.1 specifications).
  4. Develop a test suite and address any issues in the Last Call document (of course, also fix these issues in the CG version of the spec).
  5. As per W3C process, substantive and minor changes to Last Call documents have to be reported and raised issues addressed before the spec can progress to the next level : Candidate Recommendation status.
  6. For the next step – Proposed Recommendation status – an implementation report is necessary, and thus the test suite needs to be finalized for the given feature set. The feature set may also be reduced at this stage to just the ones implemented interoperably, leaving any other features for the next version of the spec.
  7. The final step is Recommendation status, which simply requires sufficient support and endorsement by W3C members.

  The first version of the WebVTT spec naturally has a focus on captioning (and subtitling), since this has been the dominant use case that we have focused on this far and it’s the part that is the most compatibly implemented feature set of WebVTT in browsers. It’s my expectation that the next version of WebVTT will have a lot more features related to audio descriptions, chapters and metadata. Thus, this seems a good time for a first version feature freeze.

  There are still several obstacles towards progressing WebVTT as a milestone of the TT-WG. Apart from the need to get buy-in from the TT-WG, the TT-CG, and the AC (Adivisory Committee who have to approve the new charter), we’re also looking at the license of the specification document.

  The CG specification has an open license that allows creating derivative work as long as there is attribution, while the W3C document license for documents on the recommendation track does not allow the creation of derivative work unless given explicit exceptions. This is an issue that is currently being discussed in the W3C with a proposal for a CC-BY license on the Recommendation track. However, my view is that it’s probably ok to use the different document licenses : the TT-WG will work on WebVTT 1.0 and give it a W3C document license, while the CG starts working on the next WebVTT version under the open CG license. It probably actually makes sense to have a less open license on a frozen spec.

  Making the best of a complicated world

  WebVTT is now proposed as part of the recharter of the TT-WG. I have no idea how complicated the process will become to achieve a W3C WebVTT 1.0 Recommendation, but I am hoping that what is outlined above will be workable in such a way that all of us get to focus on progressing the technology.

  At TPAC I got the impression that the TT-WG is committed to progressing WebVTT to Recommendation status. I know that the TT-CG is committed to continue developing WebVTT to its full potential for all kinds of media-time aligned content with new kinds already discussed at FOMS. Let’s enable both groups to achieve their goals. As a consequence, we will allow the two formats to excel where they do : TTML as an interchange format and WebVTT as a browser rendering format.

• WebVTT as a W3C Recommendation

  1er janvier 2014, par silvia

  Three weeks ago I attended TPAC, the annual meeting of W3C Working Groups. One of the meetings was of the Timed Text Working Group (TT-WG), that has been specifying TTML, the Timed Text Markup Language. It is now proposed that WebVTT be also standardised through the same Working Group.

  How did that happen, you may ask, in particular since WebVTT and TTML have in the past been portrayed as rival caption formats ? How will the WebVTT spec that is currently under development in the Text Track Community Group (TT-CG) move through a Working Group process ?

  I’ll explain first why there is a need for WebVTT to become a W3C Recommendation, and then how this is proposed to be part of the Timed Text Working Group deliverables, and finally how I can see this working between the TT-CG and the TT-WG.

  Advantages of a W3C Recommendation

  TTML is a XML-based markup format for captions developed during the time that XML was all the hotness. It has become a W3C standard (a so-called “Recommendation”) despite not having been implemented in any browsers (if you ask me : that’s actually a flaw of the W3C standardisation process : it requires only two interoperable implementations of any kind – and that could be anyone’s JavaScript library or Flash demonstrator – it doesn’t actually require browser implementations. But I digress…). To be fair, a subpart of TTML is by now implemented in Internet Explorer, but all the other major browsers have thus far rejected proposals of implementation.

  Because of its Recommendation status, TTML has become the basis for several other caption standards that other SDOs have picked : the SMPTE’s SMPTE-TT format, the EBU’s EBU-TT format, and the DASH Industry Forum’s use of SMPTE-TT. SMPTE-TT has also become the “safe harbour” format for the US legislation on captioning as decided by the FCC. (Note that the FCC requirements for captions on the Web are actually based on a list of features rather than requiring a specific format. But that will be the topic of a different blog post…)

  WebVTT is much younger than TTML. TTML was developed as an interchange format among caption authoring systems. WebVTT was built for rendering in Web browsers and with HTML5 in mind. It meets the requirements of the <track> element and supports more than just captions/subtitles. WebVTT is popular with browser developers and has already been implemented in all major browsers (Firefox Nightly is the last to implement it – all others have support already released).

  As we can see and as has been proven by the HTML spec and multiple other specs : browsers don’t wait for specifications to have W3C Recommendation status before they implement them. Nor do they really care about the status of a spec – what they care about is whether a spec makes sense for the Web developer and user communities and whether it fits in the Web platform. WebVTT has obviously achieved this status, even with an evolving spec. (Note that the spec tries very hard not to break backwards compatibility, thus all past implementations will at least be compatible with the more basic features of the spec.)

  Given that Web browsers don’t need WebVTT to become a W3C standard, why then should we spend effort in moving the spec through the W3C process to become a W3C Recommendation ?

  The modern Web is now much bigger than just Web browsers. Web specifications are being used in all kinds of devices including TV set-top boxes, phone and tablet apps, and even unexpected devices such as white goods. Videos are increasingly omnipresent thus exposing deaf and hard-of-hearing users to ever-growing challenges in interacting with content on diverse devices. Some of these devices will not use auto-updating software but fixed versions so can’t easily adapt to new features. Thus, caption producers (both commercial and community) need to be able to author captions (and other video accessibility content as defined by the HTML5 element) towards a feature set that is clearly defined to be supported by such non-updating devices.

  Understandably, device vendors in this space have a need to build their technology on standardised specifications. SDOs for such device technologies like to reference fixed specifications so the feature set is not continually updating. To reference WebVTT, they could use a snapshot of the specification at any time and reference that, but that’s not how SDOs work. They prefer referencing an officially sanctioned and tested version of a specification – for a W3C specification that means creating a W3C Recommendation of the WebVTT spec.

  Taking WebVTT on a W3C recommendation track is actually advantageous for browsers, too, because a test suite will have to be developed that proves that features are implemented in an interoperable manner. In summary, I can see the advantages and personally support the effort to take WebVTT through to a W3C Recommendation.

  Choice of Working Group

  FAIK this is the first time that a specification developed in a Community Group is being moved into the recommendation track. This is something that has been expected when the W3C created CGs, but not something that has an established process yet.

  The first question of course is which WG would take it through to Recommendation ? Would we create a new Working Group or find an existing one to move the specification through ? Since WGs involve a lot of overhead, the preference was to add WebVTT to the charter of an existing WG. The two obvious candidates were the HTML WG and the TT-WG – the first because it’s where WebVTT originated and the latter because it’s the closest thematically.

  Adding a deliverable to a WG is a major undertaking. The TT-WG is currently in the process of re-chartering and thus a suggestion was made to add WebVTT to the milestones of this WG. TBH that was not my first choice. Since I’m already an editor in the HTML WG and WebVTT is very closely related to HTML and can be tested extensively as part of HTML, I preferred the HTML WG. However, adding WebVTT to the TT-WG has some advantages, too.

  Since TTML is an exchange format, lots of captions that will be created (at least professionally) will be in TTML and TTML-related formats. It makes sense to create a mapping from TTML to WebVTT for rendering in browsers. The expertise of both, TTML and WebVTT experts is required to develop a good mapping – as has been shown when we developed the mapping from CEA608/708 to WebVTT. Also, captioning experts are already in the TT-WG, so it helps to get a second set of eyes onto WebVTT.

  A disadvantage of moving a specification out of a CG into a WG is, however, that you potentially lose a lot of the expertise that is already involved in the development of the spec. People don’t easily re-subscribe to additional mailing lists or want the additional complexity of involving another community (see e.g. this email).

  So, a good process needs to be developed to allow everyone to contribute to the spec in the best way possible without requiring duplicate work. How can we do that ?

  The forthcoming process

  At TPAC the TT-WG discussed for several hours what the next steps are in taking WebVTT through the TT-WG to recommendation status (agenda with slides). I won’t bore you with the different views – if you are keen, you can read the minutes.

  What I came away with is the following process :

  1. Fix a few more bugs in the CG until we’re happy with the feature set in the CG. This should match the feature set that we realistically expect devices to implement for a first version of the WebVTT spec.
  2. Make a FSA (Final Specification Agreement) in the CG to create a stable reference and a clean IPR position.
  3. Assuming that the TT-WG’s charter has been approved with WebVTT as a milestone, we would next bring the FSA specification into the TT-WG as FPWD (First Public Working Draft) and immediately do a Last Call which effectively freezes the feature set (this is possible because there has already been wide community review of the WebVTT spec) ; in parallel, the CG can continue to develop the next version of the WebVTT spec with new features (just like it is happening with the HTML5 and HTML5.1 specifications).
  4. Develop a test suite and address any issues in the Last Call document (of course, also fix these issues in the CG version of the spec).
  5. As per W3C process, substantive and minor changes to Last Call documents have to be reported and raised issues addressed before the spec can progress to the next level : Candidate Recommendation status.
  6. For the next step – Proposed Recommendation status – an implementation report is necessary, and thus the test suite needs to be finalized for the given feature set. The feature set may also be reduced at this stage to just the ones implemented interoperably, leaving any other features for the next version of the spec.
  7. The final step is Recommendation status, which simply requires sufficient support and endorsement by W3C members.

  The first version of the WebVTT spec naturally has a focus on captioning (and subtitling), since this has been the dominant use case that we have focused on this far and it’s the part that is the most compatibly implemented feature set of WebVTT in browsers. It’s my expectation that the next version of WebVTT will have a lot more features related to audio descriptions, chapters and metadata. Thus, this seems a good time for a first version feature freeze.

  There are still several obstacles towards progressing WebVTT as a milestone of the TT-WG. Apart from the need to get buy-in from the TT-WG, the TT-CG, and the AC (Adivisory Committee who have to approve the new charter), we’re also looking at the license of the specification document.

  The CG specification has an open license that allows creating derivative work as long as there is attribution, while the W3C document license for documents on the recommendation track does not allow the creation of derivative work unless given explicit exceptions. This is an issue that is currently being discussed in the W3C with a proposal for a CC-BY license on the Recommendation track. However, my view is that it’s probably ok to use the different document licenses : the TT-WG will work on WebVTT 1.0 and give it a W3C document license, while the CG starts working on the next WebVTT version under the open CG license. It probably actually makes sense to have a less open license on a frozen spec.

  Making the best of a complicated world

  WebVTT is now proposed as part of the recharter of the TT-WG. I have no idea how complicated the process will become to achieve a W3C WebVTT 1.0 Recommendation, but I am hoping that what is outlined above will be workable in such a way that all of us get to focus on progressing the technology.

  At TPAC I got the impression that the TT-WG is committed to progressing WebVTT to Recommendation status. I know that the TT-CG is committed to continue developing WebVTT to its full potential for all kinds of media-time aligned content with new kinds already discussed at FOMS. Let’s enable both groups to achieve their goals. As a consequence, we will allow the two formats to excel where they do : TTML as an interchange format and WebVTT as a browser rendering format.