A small JavaScript snippet captures everything on your website – every page, click, mouse movement, and dynamic state change.
Record all interactions of your visitors on your web to understand customer experience.
You can easily exclude sensitive user’s information so it never touches our servers.
Quotient announced last week that it’s buying Ubimo, an Israeli location intelligence company. Ubimo translates location data and history into audience segmentation, activation and campaign attribution, connecting digital campaigns to in-store results.
DSP was the attraction. Quotient and Ubimo had worked together for several years, utilizing the latter’s data for Quotient customer campaigns. But the primary rationale behind the acquisition was Ubimo’s DSP, according to Jason Young is Quotient’s Chief Marketing & Media Officer.
Quotient intends to offer its CPG brand and agency clients a self-service DSP. “The acquisition will accelerate Quotient’s product development of a self-service platform, where marketers can plan, buy, and optimize media campaigns directly from an automated platform,” according to the Quotient’s press materials.
Coupons.com evolved. Quotient began life as Coupons.com in 1998, which it still owns and operates. In 2017, the company acquired mobile marketing company Crisp Media for roughly $53 million.
Quotient distributes digital coupons through its network, which includes Coupons.com and a wide range of retailers and grocery store properties. The company also makes programmatic media buys on behalf of customers.
Through loyalty cards and point-of-sale (POS) redemption data, Quotient is able to deliver closed loop reporting as well. It also uses POS data for campaign targeting.
For retailers, Quotient offers a range of ad and media solutions. For example, it enables retailers to sell ad space on their sites and apps and distribute digital circulars on social media. It also operates an influencer marketing platform.
Utility of location data. Brands that don’t have access to coupon or loyalty card POS data, have increasingly used store visitation as an attribution metric. That’s one of the primary capabilities Ubimo offers its customers.
But Ubimo also uses location data, which can be combined with other data sets, to enable highly specific audience segmentation and targeting. Quotient will bring Ubimo’s technology into its platform and combine its own shopper data with Ubimo’s location data and analytics, which Quotient “expects to meaningfully improve campaign performance for customers.”
With Ubimo’s assets and customer relationships, Quotient intends to expand beyond its traditional CPG and retail customer/partner base and move into “adjacent markets, such as Out-of-Home.”
Why we should care. Quotient’s main reason for buying Ubimo was the company’s DSP. But from a larger market perspective, the deal shows the increasingly mainstream use of location intelligence, both for targeting and attribution. It also shows a growing recognition of the power of location data for merchants and brands — unless they sell exclusively online — to maximize targeting effectiveness and to demonstrate the real-world impact of digital campaigns.
The other day I was listening to the latest Shop Talk Show podcast while out for my morning run. They had Jen Simmons on the show, talking about (among other things) the standards process. It’s a great conversation, as you would expect—Jen’s super smart and has been doing great, meaningful work for a long time.
Among the things that she discussed is the care that has to go into new browser features because once shipped, it’s there for good. Most of us don’t have to worry about things to that same level because:
…you can always delete all your code later. You can always say, ‘Oh, this thing I shipped quickly for my project, that was a bad idea. Let’s obliterate it and re-do it better later.’ But with the web, there’s two things. One, we don’t get to change it and ship it again later, almost ever. If we hurry up and we ship subgrid, and subgrid is crappy, there’s no, like, fixing it. We’re stuck with it.
This permanence to the web has always been one of the web’s characteristics that astounds me the most. It’s why you can load up sites today on a Newton, and they’ll just work. That’s in such sharp contrast to, well, everything I can think of. Devices aren’t built like that. Products in general, digital or otherwise, are rarely built like that. Native platforms aren’t built like that. That commitment to not breaking what has been created is simply incredible.
Jen’s other point, too, is an important one to remember:
…And the other thing is that we’re not solving for one website. We’re not solving for facebook.com, or youtube.com, or codepen.io or for…whatever. We’re solving for the entire web and every use case ever all at the same time.
She gives an example, later on, discussing how even something seemingly simple, underlines, becomes so much more intense when you need to solve for everyone:
Well, what about these languages that are typeset vertically? What is the typography in Japan? What’s needed for this kind of script that is completely different than the Latin alphabet? And there’s a long conversation about that and then, ‘Wow, we’re shipping something that actually works for all the languages and all the scripts around the world.’ Or it almost does and there’s a few pieces missing but we’re dedicated to going ahead and finishing those pieces as soon as we can.
There’s a lot of thought and consideration that goes into deciding what makes its way into this incredible platform and what doesn’t.
Another person I have a ton of respect for and who has been doing incredibly important work for a long time is Alex Russell. In particular, he’s put an absurd amount of time and energy into advocating for being careful about the overreliance on JavaScript that is leading to much of the web’s current performance issues.
I thought about Jen’s comments when I saw one person stating that Alex was trying to “sell you on fairy tales of Use the Platform”.
I don’t want to single that person out because I’m not here to encourage a pile-on, but also because they’re hardly the first person to express that general sentiment. But, that statement about the “fairy tale of Use the Platform” has really stuck with me, because it feels…wrong.
So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there? I don’t mean that to be perceived as throwing shade (as the kids say). Building the actual web platform requires a deeper level of commitment to these sorts of things out of necessity.
And as some frameworks are, just now, considering how they scale and grow to different geographies with different constraints and languages, the web platform has been building with that in mind for years. The standards process feels so difficult to many of us because of the incredible amount of minutiae that becomes critical. That security issue that might maybe be a problem? Maybe you feel comfortable taking that risk but when you’re creating something that everyone, everywhere is going to use, it becomes a valid reason for not shipping.
People talk a lot about the web being accessible or performant by default, and while it’s not perfect, it’s also not that far from being true. Creating the platform means you have to prioritize these things.
If you care at all about reaching people outside of the little bubbles we all live in, using the platform can’t be a fairy tale: it has to be the foundation for everything that we build.
That doesn’t mean that foundation is enough, or always right.
Are there limitations? Absolutely! There’s a reason why we still have a standards body, 26 years or so after HTML was first specified: because the work isn’t done and never (knock on wood) will be. (It’s also why I find it very encouraging that folks like Nicole Sullivan are hard at work to identifying some of the things we need frameworks for that should probably be in the browser instead.)
The web thrives on a healthy tension between stability and the chaos of experimentation. It’s perfectly fine, and necessary at times, to use tools to augment issues and limitations we may have on the web. I have no problem with that at all.
But it’s important that we do so very carefully because there are definite trade-offs.
To create the standards that make it into the platform, careful care is given to each and every feature to minimize the security risks. Every new feature has to be carefully considered from an accessibility perspective to make sure that not only does it not cause harm, but that assistive technology has all the information it needs to be able to provide people with a usable experience. Performance has to be top of mind for each new standard, to ensure that shipping it won’t cause undo bloat or other performance issues.
And each of these things must not be considered simply in one single context, but for all sites and across geographies, languages, devices, and browsing clients.
Can you say, with confidence, that the same level of care is given in the tools and frameworks we use or build?
Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.
The CDP Institute has released it’s CDP Industry Report for July 2019 (registration required), and its findings indicate that while there are no signs that the industry will slow down, mergers, acquisitions and enterprise providers entering the space may drive a shift that impacts the industry as a whole.
According to the CDP Institute, the first half of 2019 brought plenty of growth to the Customer Data Platform (CDP) industry, adding 19 new vendors, bringing the total CDP vendor count to 96, employing over 9,000 workers and raking in $2.4 billion in funding.
plans for CDPs earlier this year, all of which are expected to be released before the end of 2019.
Two notable CDP acquisitions also occurred during this period, with Informatica’s purchase of identity resolution provider Allsight and Dun & Bradstreet’s acquisition of Lattice Engines. Both buyers were notably not part of the current marketing technology landscape.
As the martech industry continues to grow, marketers can anticipate that CDPs will continue to expand their capabilities to serve their customers’ needs in order to maintain growth. We can also expect that more enterprise martech providers are going to jump in with their own CDP solutions in an attempt at keeping existing customers within their own product ecosystems.
With some of the largest enterprise players in martech entering the field, the CDP game may need to change in order for smaller organizations to remain competitive. Some CDPs may be positioning themselves for strategic acquisitions by larger vendors looking to add CDP capabilities to their existing suite of solutions.
This morning, I took a Jump bike to my office in San Francisco. As I write this, an Uber driver in Bangkok is taking a customer home on a tuk-tuk; a busy family in Birmingham has ordered dinner on Uber Eats; and commuters in Denver are holding train tickets purchased on Uber Transit. There is even a decent chance that you’re reading this while taking an Uber.
As Uber’s products scale and our portfolio expands, the landscape of variables and locales that we design for also evolves. With over 10 million trips happening a day, how can we ensure a positive, reliable experience for everybody?
The answer is our Design Platform. By creating a system that not only acknowledges but also leverages Uber’s evolution into a platform, we support our designers with a robust, consistent set of basic elements while enabling them to freely explore.
We’ve introduced Uber’s apps and services at lightning speed. In the beginning, our decentralized system allowed us to innovate and experiment. This gave us the power to introduce innovative design patterns, but it also fragmented our user experience. We realized that although the use cases for riders, drivers, and eaters may be quite different from each other, the experiences that shaped their interactions shared some underlying foundational patterns. By paying attention to these common patterns, we can ensure a coherent experience across products and locales.
Today, Uber is a platform: the variety of services we offer feed into a single ecosystem whose strength is built on how — and how well — those services interconnect. As our platform evolves, so does our process for how we design at scale.
We need tools that help designers stay in sync, common design libraries that provide them with our growing body of learnings and the means to recognize and apply our patterns to a diversity of user experiences.
This system must be able to welcome incoming innovations without disrupting the existing experiences that feel familiar to so many users.
By grounding design at its basic level, we built a flexible system that empowers designers with the freedom to explore while keeping consistency and quality at the core.
In 2018, we created a web React library and released it to the public as the Base Web open-source project. We called it “Base” because it focused on the basics, such as typography, color, grid, and iconography, as well as essential elements like buttons, lists, and controls. Today, it has become the UI framework for all our products.
The design system is the first piece of the puzzle, not the last, and should help design faster while maintaining high standards and consistency. That’s why we conceived Base to be dead simple. It has four font categories, three main colors — white, black, and an accent color — and five core sizes based on a four-pixel grid.
It’s like playing with LEGO: single bricks can make up so many constructions. The basic brick doesn’t change, but the builder uses it to create, unleashing its potential. While these components are basic at their core, they also highly customizable through style overrides and can be configured in many different ways.
Connecting our design into a single system allows us to think beyond pixels. Designing at Uber is first and foremost about recognizing how the virtual and physical worlds interact and how our digital affordances have wide implications that affect user behaviors and our society: this is something that we refer to as designing for patterns. Having a clearly delineated design system with supporting tools not only helps designers avoid wasting time while “pushing pixels,” but frees them to focus on identifying such patterns and designing for positive impacts in the real world.
Designers are creatures of habit. Breaking the momentum of focus is a bummer when you constantly need to leave your workspace to find reference documentation.
In the past, we’d created internal websites that featured our style guide, but this required maintenance risked becoming obsolete and was yet another place you had to go to find relevant information. Today, we write our documentation right into the tools.
We turned to Figma as our main design software for its powerful collaboration features. Because this means that our work files live exclusively on the cloud, we can maintain a single source of up-to-date documentation. We manage a comprehensive library where we not only publish and update our UI components, but where we also write supporting guidelines, build lists of Dos and Don’ts, and showcase good examples. One key benefit of a live system is that we only need to maintain a single file: a single place designers can turn to for everything they need.
Icon libraries and icon styles had historically differed across each of Uber’s products. Originally this approach seemed to make sense, given that riders, drivers, and eaters all have entirely different contexts. But we realized that a common set of transportation and lifestyle icons worked across every single one of our products, both internal and external.
Now we have a unified system of iconography, illustrations, and assets. Design teams at Uber can make new requests, and these are fulfilled by a single creative team.
Our assets are used by a variety of disciplines with very specific needs, including product design, marketing, and engineering. To save resources and optimize our workflows, we have created differentiated access points to serve those needs, while maintaining a single system. Designers, who use Figma, can access our vector assets directly in a shared library. We diligently tag each component with keywords to make searching easy.
Marketing specialists are not always familiar with design tools like Figma; they mostly need PNGs. We built a super-fast internal website that pulls images directly from the Figma file, with search powered by keywords added to the original component. This way, even people who are not familiar with design software can access the assets they need.
After several years of experimenting with different approaches, we’ve learned that the key to creating and keeping momentum is the community that grows around the system.
One little tool we invested in is what we call DesignKit. It’s a simple Mac OS menu bar extension that gives designers quick access to our tools. We can update DesignKit’s content on the fly so that it can always surface what’s new and relevant. One of its most convenient features is the ability to send native push notifications. Emails and newsletters don’t really serve the need to communicate brief, simple updates to a design system, and the number of emails can be overwhelming. Thanks to DesignKit, we can send quick updates without overloading designers with extraneous communication.
Design ultimately happens through collaboration, discussion, experience, and hard work. To keep tabs on what product designers are working on, we are scrupulous about allocating time for design critiques, 1:1 meetings, workshops, and many other formal and ad-hoc occasions for in-person communication.
Culture also plays an essential role. At Uber we encourage our designers to design in the open, to constantly share ongoing work, and to collaborate. In that spirit, our design system is not a set of rules that we enforce through a series of gates and control processes, but rather an inclusive, constantly evolving ecosystem where everyone is invited to participate. The more we all participate, the better the system gets.
The ultimate goal of our design platform is to make every designer a little better at thinking of everything in terms of systems — grids, typography, language, motion, accessibility, and so on. This allows everyone to design together, to learn from a common source, and to have a shared understanding of product quality across the company.
If you are interested in joining our team, please check out the current job listings.
The only platform for building native mobile, desktop and WebAssembly with C#, XAML from a single codebase. Open source and professionally supported.
Get Started
Uno Platform makes a great choice for modern .NET developers.
Uno Platform updates in sync with the latest WebAssembly advancements. Just give it a shot in the playground below. Uno-built native apps can be compiled to WASM with no additional development efforts!
Smart developers reuse. Your business logic and UI layer will be close to 100% compatible across native mobile, web and desktop.
If you speak C#, XAML and use Visual Studio you will feel at home. Ramp up time is minimal and you can take advantage of all that the Visual Studio ecosystem has to offer for testing, deploying, project management, and more.
Seeing is believing. Learn by doing. See code samples our engineers put out for fun, learning and reuse. Explore the possibilities Uno Platform opens.
Check out our sample app and our gallery demo app to experience the performance and the native look and feel of Uno Platform-powered apps.
