See also: IRC log
<manu> scribe: manu
Linda: Welcome everyone, thanks for joining. Let's do a short introduction.
alake: Hi, Adam Lake from Digital Bazaar - Business Development
amber: Amber with GS1 US and global standards team.
Bob: Bob Burke with Koupon Media, CTO
Brian: Brian Russell, Technical Business Analyst with Verifone
Ed: Ed with W Capra Consulting Group
Jay: Jay Johnson with QPles, representing ACT and JICC board from Digital Couponing
John: John Morgan with association of coupon professionals (ACP)
Kylie: Kylie, consultant from Accenture
Manu: Manu Sporny, Digital Bazaar.
Simon: Simon Stocks from IFSF
Ian: Ian Jacobs, Payments lead from W3C. Excited to see folks here from various digital offers organizations.
Andre: Andre Lyver from Shopify
Linda: Linda Toth from Conexxus, Chair for the CG here.
Jay: I work on the enablement
committee with John Morgan, GS1 Project on next generation
coupons. Coming into this from a digital standpoint. Our
industry, some background first.
... People come at this from different areas, so trying to get
a bit of a baseline established.
... The industry itself is broken out into four different
groups: FSIs - what you get in your newspaper. In the store,
generally a pre-printed offer in a printing press, comes in
mail, newspaper, circulars.
... That's the biggest of the share of the market
... print at Home is when you're on a website, see a coupon,
print it, take it to local grocer and redeem it there. FSI - so
much cost assocaiated with that... 1/2% of everything that's
sent out is redeemed, usually... 3/4%
... Ripe for fraud in certain cases, print with PDF, print as
many copies as you'd like with Print at Home- Qples has gotten
around that, but still fraud in industry.
... Load to Card - instead of printing, pushing to Kroger card,
something readily available at grocery store, similar to
digital wallet, closed circuit, only applies to that grocery
store.
... Last one is Rebate - you go in, buy all your stuff, take a
picture of your receipt, get a rebate.
... Load the card, people don't care for it, but really only
digital solution we have so far... head of CIC (FBI of
couponing) said it was a "bridge to nowhere". Don't know where
they can be used, etc,
... Brands don't care for it, no longer Coca Cola coupon...
brands aren't as keen on it, money isn't there immediately for
Rebates.
... Those are the four general types.
... This is, in many ways, an archaic industry. Long before
digital, lots of cost setting up presses. Very costly.
... When Internet started off, it went to Print at Home,
instead of waiting to reinvent. They folded this onto actual
printing model. Much of terminology that you have in FSI is in
Print at Home. When Load to Card / Click to Card bolted itself
on to traditional print model.
... Standards and specs that we had originally, all of these
different types of coupons, bolted on, assuming that was the
correct methodology, when GS1 (Amber can speak more to this),
it stored so much data in it, allows us a way to be more
specific, be more data driven, to really eliminate a lot of
fraud. Instead of bolting on what we have to existing systems,
we wanted instead to create new standards. Existing bar codes
have a prefix of 8110 and those
are for Print at Home coupons.
Jay: ACT and JICC, when they went to GS1 and asked for a new specification, a new type of barcode, 8112. This project is meant to bring mobile redemption into current coupon market. We can differentiate for mobile coupon.
<Ian> 8112 press release -> http://www.gs1us.org/about-gs1-us/media-center/press-releases/digital-couponing-standard
Jay: Putting that same 8110 on a
mobile device is not a solution, you may have a 100 coupons,
but only 90 were printed at home, no way to do
reconcilation.
... GS1 and JICC setup a new type of bar code, several
different standards that were key to this project, mobile
redemption, needed to replace mobile coupons, reconciliation,
established a few requirements that were in there.
... Not being able to scan directly from mobile screen -
controversial - reason was to prevent screen shotting coupon
and using it over and over. Handing cell phone over loses the
security side of this, we don't want that to be the standard
way this is used.
... We want to allow for the coupon to get from the mobile
device to the computer, multiple companies working on that.
Must be secure.
... Right now, we have fraud in the industry... we can focus on
a few things to eliminate a great deal of this. The solution
needs to be retailer agnostic.
... This is an easy path, every single POS system has different
software, upgrades, hardware. There is not just one standard
through the industry. How do you work with all retailers and
POS systems? That's a bit of a task.
... We want "kill the till" - each bar code would have a unique
bar code, register would tie into a database, can't use it more
than once, dead after you use it, makes for a secure
transaction.
... We haven't approved anything yet, close to having
this.
... One of the technologies that we identified is the "Belgian
Model" - being used in a lot of European countries.
... This is a bit cumbersome, five steps, a bit clunky, able to
go through it, great strides in what we're trying to
accomplish. Encouraged what we can do state side here, make it
a better experience.
... Goes from manufacturer, create an offer, go into data pool,
once you redeem a coupon, a retailer scans, sends data to data
pool, coupon master data makes sure it's good, sends it back to
retailer.
... Goes to clearing houses, do reporting after that. Some of
the challenges are adoption - not strong adoption.
... In US, we have the ability to get more adoption w/
retailers. What we want to do, Linda and I talked, was on JICC
calls, she wanted us to share with W3C see if there are
similarities. Being able to work with W3C gives us a lot more
widespread technology that would work with petro markets.
... Convenience stores, places like that. Online might work
better online, more secure, more online, take to brick and
mortar, etc.
... In some of the conversations that we've had, this is a
great opporotunity to talk about overlap. Glad to be
represented here and work with it. Wraps up what our industry
does.
<ltoth> q
<Zakim> Ian, you wanted to ask about no scanning from screen requirement
Ian: Could you share that
presentation link with us?
... No scanning directly from mobile screens - can you say more
about that? Why would there be such an explicit user experience
limitation?
Jay: Think about using it? Barista doesn't read what offer is, they just scan. From a technology standpoint, you can forge that and they not pay attention to that. We wanted security items to be behind the screen - Groupon offers for example, you can screen shot those easily, opened themselves up for fraud.
<Ian> scribenick: Ian
<manu> Jay: This is a hot button issue, we don't want to get a cashier in this loop, we would like to get that security out of their hands and put it in the back end. NFC in some sort of way. If you start scanning, it becomes habit, not reading screen anymore, red light doesn't go off, mis scanned, this is why we wanted to take it out.
<manu> John: The biggest thing is the fraud issue. If you scan a phone, you can't prevent or make it go viral. Manufacturers want to control distribution.
<ShaneM> late regrets - sorry. I am tied up in another meeting that Just. Won't. End.
<ed_c> +q
<manu> John: On retailer side, having a fist full of coupons, worst thing in long lane - a fist full of coupons.
<manu> John: You want to process the person and get them out of the store quickly.
<manu> Jay: If you have scanning issues w/ phones while people are going through line, that causes some frustration.
other user experience friction: hard to scan due to dirty screen, cracked screen, etc.
<manu> John: The seller doesn't want the 15 dollar cashier holding on to $500+ phone.
<manu> Amber: Retail, apparrel, those are all closed loop systems - we want open loop. That's where fraud could come in.
manu: Thank you for the overview.
<Zakim> manu, you wanted to ask about required data formats? protocols?
manu: I am wondering if there are
other requirements you've discovered. For example, are there
data formats that are "must haves" or protocols that are
required? Or exchanges?
... it would be good to understand the industry requirements so
that in a W3C context people have a better understanding of
them
Jay: not currently
<manu> Jay: We've been looking at several things, infrared instead of scanning, for example. Push to a scanner. The way they calibrate the scanner, they beam infrared into scanner, they used that same technology to push information into it. Very limited technology.
<manu> Jay: We've also explored some mobile wallets.
<manu> Jay: As far as specifications and protocols, we're exploring protocols, make sure they're secure, commonly used, set, standard used in all of industry. Once we come to a steadier landing point, we could talk offline on some of these ideas, technologies that could be used. I know Conexxus has been working on pay at the pump.
<manu> Jay: There are some interesting opportunities here.
<manu> Amber: It seems like every few weeks there is a new use of 8112 barcode. Online grocery pickup and delivery, how is that integrated? From a standards viewpoint, potential use cases are primary, meet all industry needs, reduce fraud, that's what I care about.
<manu> Jay: Amber is a wealth of knowledge around this stuff.
<manu> John: 8112 is a flexibility on the model, we're expecting lots of flexibility. We are headed toward more flexibility, various types of offers, depending on what this group wants to do with offers, flexibility may be an expectation from Manufacturers.
<manu> ltoth: Jay, question for you... Database itself, who manages that?
<manu> ltoth: Who pays for that?
<ed_c> -q
<manu> Jay: In Belgian model, it's a privately owned company authorized by GS1, ordained to be master list.
<ed_c> regrets need to leave early
<manu> Jay: We've identified a few companies that have done this in gift card space, phone card, purchase card, long distance minute sales, those types are existing, they already have knowledge to do the data. Looking at their technologies, haven't approved that technology, leading in that direction.
<Zakim> manu, you wanted to ask about over the top / into the cloud. and to ask about if we're limited to bar codes and not just data?
manu: Are you looking at
scenarios where customer has access to the internet? (So that
the handshake happens via IP rather than POS)
... also there's a lot of discussion around 8112 and bar codes,
but also exchange of rich data.
... how tied to bar codes are we ? And dependency on small data
packages?
... has there been discussion of what data looks like in a post
bar code world?
... or bar code used as front end to richer data
experience?
Jay: +1 to richer experience
(e.g., through user connection over IP)
... I'd like to use consumer's mobile device, but there are
challenges (e.g., limitations in user data plans)
... mobile wallets may alleviate some concerns - users are
making choice to use them; they are also not tied to individual
organizations
<manu> Jay: With respect to cloud - very happy to hear that... that's a great option. I'd like to use mobile device for customer. Those are some legal hurdles. However, answers that we've seen, if we can get around that, mobile wallets, your choice - transfer use - individual providers, grocery stores, once we establish that handshake, there is a lot of information we can exchange.
<manu> Jay: When we were talking about Verifiable Claims, that's when I get really excited about all of this. With this database, there is a lot of interaction between the two, demographics, eligible to buy alcohol, tobacco, milk (dairy is more regulated on a state basis than alcohol and tobacco), prescriptions, alcohol, tobacco.
Jay: and dairy
<manu> Jay: There are ways that we can integrate that, use those databases, getting that handshake setup, once it's made, we're wide open to data that can be used and stored.
<manu> John: 8112, back to barcodes on phone, 8112 is data string that gets validated.
<manu> John: There is a lot of stuff that app companies may have, integrity of that validation system, fraud/risk that we're trying to control.
<manu> Amber: On "barcodes", it might be naieve to say that we won't have barcodes on phones. Consumer ease of use is key, but not everything is going to require barcodes. We have a 70 character limit on b arcodes, but 2D matrix barcodes can store 2000 characters, but none of this should require a barcode if everyone's technology works as it should.
<manu> Brian: With respect to use on consumer device, potential delay in the lane as the cashier does stuff, if they have to coordinate, it seems like we should limit involvement back and forth as it could slow down checkout.
<manu> Jay: Agree, once the handshake is made, all data is available. We don't want to ping pong back and forth between the cashier and customer.
<manu> Jay: Once handshake is made, all data is readily available.
<manu> Linda: With that, we have 15 minutes left. Thank you Jay, John, and Amber, good information here.
<manu> Linda: Brian, you mentioned that this should happen sooner than later.
<Zakim> Brian, you wanted to discuss how much use of consumer device
<manu> Brian: We need a standard that is usable by all verticals, there is a number of groups involved - very difficult for global work, so one thing was if there could be a divide and conquer mentality, some groups could work on specific things, others could work on others. Past experience in Conexxus world, had to create global standard if there are multiple groups working in different groups.
<manu> Brian: Could there be a coming together of these efforts to compress some of that time? We were talking years, don't see how that works with this type of effort.
<manu> Ian: It's exciting to see people from a variety of organizations talking together. It's constructive to share different viewpoints, see if there are ways that we can work together to speed things up. We are trying to understand the various activities going on to not conflict with some, be helpful if we can, where W3C is most likely to add value is in the Web-focused space.
<manu> Ian: This may have to do with browser features that help manage/redeem digital offers, data formats, etc. I welcome these discussions. We won't jump into anything because it'll take a while to find out where we can be helpful. If we can take on too large of a task, it would be not likely to complete in a reasonable timeframe.
<manu> Ian: We want to identify the gaps in the way of high-priority innovation, be very focused, speed up the overall process. This is mostly in response to Brian's concern. We're early on in our listening phase, it's inevitable that it'll take some time to figure out where the priorities are.
<manu> DavidE: Hello, just joined.
<Zakim> manu, you wanted to ask if we've identified key stakeholders/implementers for pilots?
Manu: About timeline, I share
your concern....every working group we've participated in in
w3c and iETF...I think time and time again that both W3C and
IETF can be responsive to the market based on market
changes
... one of the things we can do in this group, as Ian said, is
to understand what each party is doing
... but another key element of success is for organizations to
experiment...trying out things in pilot programs
... this let's people come to the table with working pilots to
show traction, benefits, drawbacks
... Digital Bazaar happy to participate in pilot programs
Brian: I agree with points made about prioritization
<manu> Brian: Both of you spoke well about that idea, prioritization, important point.
<manu> Brian: Requirement to restrict scanning from phone, some qualms about that, that surprised me - that seemed like something W3C would be interested in. With Web Payments, you wouldn't scan anything from phone. W3C could help with that model, interesting point.
https://www.w3.org/community/digitaloffers/digital-offers-community-group-charter/
<manu> Ian: Again, to those folks that are in W3C format for first time, topic is timeline, wanted to reiterate - W3C process model - in this CG, Community Groups are a place for incubation. We have this draft charter. This charter says we're going to explore problems, prioritize, gap analysis, experiment with technology ideas.
<manu> Ian: The timeline for that, I'd like us to get to the experimentation phase in 2017, I expect a lot of feedback loops early on. Pick what we want to focus on. As more people get involved, that could change our direction, help us focus more quickly, that remains to be seen. That timeline is different from standards timeline. CGs don't create standards, as things get traction, as things get traction, they can advance to the W3C standard strack.
<manu> Ian: When we talk about timeline, what we expect out of this group and its charter, experimenting by end of 2017. I don't have a more detailed timeline in my head on when we start that, do a gap analysis, ideally we'd show relevance to the community by the end of next year.
Initial discussion topics -> https://www.w3.org/Payments/IG/wiki/Main_Page/DigitalOffers2016#Initial_Discussion_Topics
<manu> Linda: As far as the charter goes, we did review those on the kick-off meeting. We need feedback, haven't gotten anything, gaps from problem statements. Steven has been traveling, haven't gotten feedback on it yet. Jay, John, Amber, we had a problem statement in there about looking up things in a database, looking up family codes. We may want to modify stuff around database lookup. Can one of you take the action item to look at problem statement? Add
<manu> other language to that?
<manu> Jay: yes, I can do that.
<manu> Linda: I suggest the rest of you take a look at problem statements and charter.
<manu> Linda: Ian, next steps, once we have problem statements defined, then what's our next step?
<manu> Ian: Before we get to that, I think one of the things we did to craft these discussion topics was think about user stories.
<manu> Ian: From different stakeholder perspectives, what do people want? Merchants want to be able to push offers to customers that are geofenced. Users would like to redeem and get coupons w/o getting apps. We've expressed what we've liked to see. Basis for writing these up. useful excercise to build shared understanding.
<manu> Ian: Write down what you think about be a big win for user experience. It was very interesting to hear "scanning is an anti-pattern", please write stuff like that down. That's what we'd like to hear from you.
<manu> Ian: If Multitender payments is what we want to focus on, get people to write that down in more detail of problems they're aware of, go beyond high-level user story and in detail, get what we need to see happen, relevant standards, dive into that topic, figure out what everyone needs, what requirements are... then we can get proposals together to solve these problems. This is going to take months.
<manu> Ian: We want to write down proposals, bat that around a bit, that's one way it could work. We're not yet in the diving deeper phase, we need to hear from everyone.
<manu> Linda: Ok, next meeting is December 12th, that's the last meeting of the year. We'll then get back together in January.
<Kylie> Thanks all! Jay - thanks for the presentation. Great insights :)