June 23, 2020

Grocery in the Age of COVID-19

For the past few weeks, we’ve worked with our partners at Alpha to learn more about how grocery buying behaviors and how preferences have changed since new restrictions and processes have been rolled out nationwide.

We received responses from over 750 participants and we were also able to determine those who had used specific ordering methods—like curbside pickup, web-ordering, or app-based ordering—in order to dive deeper into the data. We believe our respondents to be representative in that they came from all regions of the country, a variety of household income brackets, and their ages ranged from 18 – 75. There we not many surprises, but we were encouraged to find a few insights in the data that we thought were worth sharing. Our three favorite insights can be downloaded in the report here.


Would you like to connect with a member of the Bottle Rocket strategy team to discuss this research in more detail? Just say the word. We'd love to connect.


June 15, 2020

The Power of Product + Marketing

The holy grail of marketing is sending the right message to the right user at the right time. Did you know that average time spent on mobile and desktop devices has increased every year over the past decade? This year, it reached a whopping seven hours per day on average.

The sheer amount of time people spend on digital devices has pushed marketing teams to adapt and begin delivering campaigns through mediums that contain functionality beyond traditional print and advertising mediums.

A lesson from the “hackvertisers”

“Hackvertising” involves closely watching conversations trending on social media to find opportunities to drive growth.

Burger King and DAVID The Agency have pioneered this strategy and are routinely supporting the continued growth of the Burger King mobile app with a progressive set of martech tools that power their marketing campaigns.

Positioning your brand’s mobile app as a centerpiece to in-flight marketing campaigns is essential for maximizing application conversion, engagement, and retention metrics.

BK marketing

A piece of marketing content that loops users into your brand’s native mobile experience will inevitably boost your chances of converting and retaining that customer for the long term.

The Burger King marketing and product teams work so closely with each other at this point, they are virtually indistinguishable.

Growth unchained

Through their use of leading martech tools and the close collaboration of their product and marketing teams, Burger King has been able to achieve some of the highest growth rates ever seen in any industry.

The latest Burger King campaigns have been so interesting, purposeful and targeted, they have literally made the world want to buy more Whoppers.

Does becoming the most downloaded app in the app store, generating over a billion impressions off a single ad campaign and generating a 54% increase in in-app sales sound like something your team would like to say in your next quarterly review with leadership?

Our suggestion: take a long, hard look at how your brand’s product and marketing teams are, or aren’t, working together. This could potentially be the gap that’s causing your brand to fall short on digital ambitions.

Go watch the recent campaign Burger King launched in  Brazil earlier last year in conjunction with DAVID The Agency if you still aren’t convinced – Burn That Ad. The innovation is jaw-dropping.

The message is the app and the app is the message

Advancements in martech over the last decade have created tools that put marketing and product teams on the same playing field.

One example: marketing teams are now able to deliver targeted emails that have embedded functionality in them that feels more like a web or mobile app than a standard email. This is something marketing teams need their product teams to build and support.

In addition, product teams are building messaging inboxes into their mobile apps for marketing teams to distribute content within. This has resulted in product and marketing teams being pushed closer and closer together as they increasingly need each other’s capabilities to achieve success and deliver on customer expectations.

With the amount of time consumers are spending on mobile devices and the number of brands competing for their attention increasing, it takes more for brands to stand out. Simply having an app and delivering messages through digital channels isn’t how brands are delivering maximum impact to consumers.

Look at the email campaigns that Pinterest is able to deliver using Accelerated Mobile Pages (AMP).

These emails are interactive and feel more like a web page or mobile app enabling Pinners to perform various actions directly in the email. This is a great example of a brand that is taking messaging to a new level with greater functionality to improve the experience and increase user engagement.

The power of these two teams is magnified once channeled together to boost conversions, engagement and retention. Failing to do so could be the difference between your brand becoming Facebook or MySpace.

This article was originally published on ClickZ.com

June 1, 2020

API Design: Empathetic Design for Technical Consumers

Design is important in many aspects of development which is especially true for development that drives user experience [1]. We’ve learned that API design can have a profound impact on user interfaces and thus user experiences. Poorly designed APIs can lead to awkward, unnatural or inefficient workflows within a user’s experience while a well-designed API can mitigate these issues or at least make it clear to consumers what all is technically possible. Ultimately, user interfaces are a representation of the underlying API.

Here are five design, implementation, performance and security best practices to keep in mind when producing APIs.

Best Practice: Make your API a Priority

APIs should be designed and developed with simplicity, consistency and ease of use in mind. Accomplishing these things may be easy in a silo but the consumer’s view may be drastically different since their needs or wants were likely not taken into account. It’s always important to design and iterate closely with consumers and/or clients before producing any long-term implementation. The best way to do this is by practicing API-First Design which is a design methodology focused on collaboration with stakeholders. Continuing with the alternative may result in an API that conforms to the existing system or simply serves as a conduit to the underlying database which will almost always ignore the client’s workflows. A great analogy exists in the construction world – you wouldn’t build a house and then draft blueprints.

Additionally, by leading with API design, it’s possible to identify API specification format and tooling from the beginning. The API specification should be described in an established format such as OpenAPI, API Blueprint or RAML. An established format is likely to have sufficient tooling that clients are familiar with like Apiary, Redocly or Swagger Hub. Depending on the time gap between API Design and client development, it may be appropriate to consider mocking functionality which most established tools will have. Mocking is a good way to give prospective consumers a tour of example data while the implementation is built out.

Best Practice: Structure with Resource Oriented Design

There is a very common architectural style known as REST [2] that has become the defacto standard on API’s for some time now. APIs that are developed using REST architecture are said to be RESTful. In general, REST provides important and well-known architectural constraints [2] but lacks concrete guidance on authoring API’s. There is an expanded architectural style known as Resource Oriented Design [3], satisfying all the constraints of REST, that serves as a good API design reference. If we’re to compare REST to SQL, Resource Oriented Design provides similar normalization properties to REST as 2NF and 3NF do for SQL. Here are a few constraints to adhere to:

  • The API URIs should be modeled as a resource hierarchy where each node is a resource or collection resource
    • Resource – a representation of some entity in the underlying application e.g. /todo-lists/1/todo-lists/1/items/1
    • Collection – a list of Resources all of the same type e.g. /todo-lists/todo-lists/1/items
  • The URI path – resource path – should uniquely identify a resource e.g. /todo-lists/1/todo-lists/56
  • Actions should be handled by HTTP Methods

Following these constraints where all practical will lead to a normalized API that’s consistent and predictable. Also, by leaving actionable verbiage out of URIs it’s easier to ensure that every resource path is a representation of some entity. This is why verbs are frowned upon in the URI as they are likely not a representation of some underlying entity – /activate is likely not a resource.

As far as the resources themselves, there is no universally accepted answer on the format used to represent them. JSON is widely adopted and understood by the majority of platforms, however, XML or other formats may serve consumers just as well or better in certain situations. The key thing is to represent resources in a way that is quick and easy for consumers to understand.

Representing resources in this fashion enables them to “speak” for themselves, known as self-descriptive resources. Self-descriptive resources that are documented using established tooling and open standards will build a sense of trust with the consumer. Ultimately, consumers should buy-in to what the API is selling without additional “fluff” material.

Best Practice: Semantics with HTTP and REST

In order to make an API come to life it needs to be actionable especially since it will likely be used to inform a client’s user interface – the buttons need to do something. Actions, in the context of REST, should be fulfilled by HTTP methods each with an intended purpose which is described here:

  • GET – query/search for resources, expected to be idempotent and thus cacheable
  • POST – most flexible REST semantic, any non-idempotent actions excluding deletes should be handled by this method
  • PUT – used to modify entire resources, yet still expected to be idempotent
  • PATCH – used to make partial modifications to resources, yet still expected to be idempotent
  • DELETE – removes a resource from the API, should be idempotent from the caller’s view

Additionally, the result of each action should be returned to the client with a proper status code as defined by the HTTP standard, not all of them most likely but most likely more than you think. Here are some common statuses that will likely be required on any API project:

  • Successful response (200 – 399)
    • 200 – responses with a body for everything besides a creation action
    • 201 – responses for creation actions
    • 202 – responses for a long running process
    • 204 – responses that don’t require a body
  • Client errors (400 – 499)
    • 400 – invalid or bad request, appropriate for syntactic errors
    • 401 – unauthenticated request due to missing, invalid or expired credentials
    • 403 – insufficient permissions e.g. wrong Oauth scope, requires admin privileges
    • 404 – resource not found e.g. represented entity does not exist in database
    • 409 – resource conflict e.g. resource already exists
    • 422 – request is syntactically valid but not semantically valid
  • Server errors (500 – 599)
    • 500 – classic internal or unknown errors for modeling exceptional/unrecoverable errors, sensitive errors or errors that can’t be elaborated on
    • 501 – method not implemented
    • 503 – server unavailable
    • 504 – timeout

For clarity, an idempotent HTTP method can be called many times with the same outcome. Consumers should be able to understand the information, relationships and operations an API is providing by the resources and methods on them alone. For example, a GET method that creates or PUT that deletes a resource will lead to an unpredictable API fraught with unexpected side-effects. Proper HTTP method and status codes, which naturally includes constraints such as idempotence, used in conjunction with self-described resources are nothing more than factual representations of the underlying business domain.

Best Practice: Maintaining Performance at the API Layer

Building a fast-performing service requires careful thought and design, often across multiple technical boundaries. The list of things to consider for performance can range from proper use of concurrency in the application on down to adequate database indexing, just depends on the requirements and needs of the business. The API can uphold performance characteristics of the underlying system in multiple ways, here’s some to consider:

  • Asynchronous Server Code – Resources that are an aggregate of multiple independent data sources can be built by the result of multiple async execution results.
  • Non-blocking Implementation – APIs that access cold I/O, are CPU intensive or just naturally slow should return with a 202 whilst processing and instruct the client where to get the result. Websockets and callbacks may be appropriate in certain situations as well.
  • Caching – Resources that change relatively slow can be cached, idempotent GET requests are the low-hanging fruit. Service level caching may suffice but a CDN may be needed depending on load.
  • Paging – Collection resources should be outfitted with paging controls for the client to limit results
  • Statelessness – Keeping track of state across requests can be complex and time consuming for the server. Ideally, state should be managed by the client and passed to the server. This applies to authentication/authorization as well. Credentials should be passed on each request, JSON Web Token (JWT) is a good option.

These considerations will go a long way towards meeting satisfactory performance metrics set by the business. Usually, business satisfaction is going to be directly tied to the satisfaction of its consumers – their satisfaction with the user experience and thus backing APIs. There has been plenty of research to show that a consumer’s user experience is tied to the response time of a page [4]. Network latency plays a big factor in page load time so it’s important to reduce this time as much as possible. A good rule of thumb is to keep API response time between 150 and 300 milliseconds which is the range for average human reaction time.

Best Practice: Securing your API

Personal and financial information is prevalent on the internet today. It has always been important to safeguard this information. However, there have been many notorious data breaches in recent times [5] that bump security considerations from just another thing to project non-starters without them. There are two good rules of thumbs when it comes to API security – don’t embarrass yourself and don’t reinvent the wheel. It’s best to leverage open standards such as OAuth or OpenID which both cover most authentication flows. It’s also advisable to delegate identity matters to purpose-built identity providers such as Auth0, Firebase, or Okta. Security is a hard thing to get right and the aforementioned vendors have solved this challenge plus gone the extra mile or two. Regardless of the standard and/or provider used, it’s always important to apply proper access controls to API resources. Resources that are sensitive should be locked down with appropriate credentials and a 401 should be returned when these credentials are not provided. In cases where a given user does not have adequate privileges to a resource, a 403 should be returned.

The best practices highlighted above are established practices in the industry that should help with any API project. By taking an API-First approach, you will be on the right path to fostering trust with your consumers and stakeholders. Practicing established REST structure and semantics as well as proper security will be huge in your endeavor. Maintaining performance will keep consumers and customers coming back for more. Ultimately, API design is part art and science. Each API will be different and there may be some pragmatic decisions to be made. However, it’s critical to not stray too far off the beaten path. 

It’s important to remember that your data and information is what your consumers and customers are truly seeking, not your radical new API design. Following these best practices will get this information to your all-important customers while keeping your consumers informed all along the way.


[1] NEA – Design in Startups Survey – https://www.nea.com/blog/the-future-of-design-in-start-ups-survey-2016-results

[2] REST – https://en.wikipedia.org/wiki/Representational_state_transfer

[3] Resource Oriented Design – https://cloud.google.com/apis/design/resources

[4] Google – Why Performance Matters – https://developers.google.com/web/fundamentals/performance/why-performance-matters

[5] Wikipedia – List of Data Breaches – https://en.wikipedia.org/wiki/List_of_data_breaches

This article was originally published on SiteProNews.com

May 18, 2020

How Mobile Experiences Can Adapt For Isolation

Technology is typically associated with the lifestyle of young people who spend too much time connected to their phones, travel around frequently and find ways to make their own lives easier by living what we often refer to as the "connected lifestyle." But what works well away from home can also work when you’re isolated at home.

In a time like this, many users are working from home, and while this may not be the norm in the future, it's important to find ways to adapt to this norm now -- for the sake of those who may find themselves in a similar situation down the road and for the sake of improving our processes overall in the long run.

Take the following industries -- and isolation-focused adaptations -- for example:

Food Delivery

Mobile ordering was originally launched as a way to help cut down the wait time at dining locations, but now we see that it is easy to transition the same ordering capabilities to a delivery service. Although not trivial, adding a delivery location and charge is only an incremental change on top of the menu and scheduling pieces that had to exist regardless.

Supporting multiple delivery locations on your profile, or suggesting prior addresses like Amazon does with their orders, would make it easier to order food for your family members that may have trouble getting out -- or for that friend who just had a baby who you’d love to visit. Support for simultaneous orders would mean you could have a videoconference meal together and rave about the local eatery while still keeping your distance.

Games And Entertainment

Digital content, both games and video, has been available through mobile devices for some time, but the advantage of everyone in the house being able to stream at the same time is even more critical when the whole family can’t leave for entertainment outside the home. Supporting more types of devices feels like a heavy lift when you assume only one or two people in a household will be using your service at once, but when everyone is home, all the screens can be in use at the same time, and that old device no one has touched in a couple of years is pulled into active duty.

Enjoying content together is a real differentiator. Simultaneous streaming of on-demand content allows that feeling of hanging around the TV watching a movie together, even if you’re apart. Some enterprising individuals have implemented this for Netflix on their own with a Chrome extension.


Independent, customized, self-paced learning has been possible for some time, but there wasn’t much opportunity to try it at a large scale. Apps like Duolingo provide flexible, gamified learning that works on the go, but also works at home with focused study.

Services should think about how they handle more dedicated sessions, as well as the bite-sized interactions that they may initially optimize for. How would you supplement the learning with additional content for those who might need to hear it explained a different way? With language apps becoming more common as a replacement for language teachers, we're seeing a huge shift in self-paced learning.


Whether in a health pandemic or not, telemedicine is seeing a huge ROI through lower costs and faster, more convenient service. Although certainly no replacement for in-person visits, it can provide a valuable service for common issues that are handled through self-care.

Although prescreening questions are helpful, dynamic versions that dig into specific issues could be even more beneficial. If someone says they have a fever, ask about the severity and duration. During flu season, ask some questions that could confirm or rule out that diagnosis. Gathering baseline metrics several weeks after treatment, and throughout the year, would be beneficial for detecting anomalies -- especially if the records could be shared across partners, or at least within the same network.

The Internet Of Things

Smart devices permeate our homes, and automation and alerts from any activity are becoming the norm. Doorbells announce a delivery, and garage doors announce departures. Cameras monitor fur babies and furless babies.

Sharing access to these devices with a “circle of trust” makes it easier for a group to monitor a single location. The security concerns around these devices are paramount, so limiting access to everyone outside the circle is critical.


The mobile revolution obviously brought better mobile tracking through apps and later wrist-mounted computers that could measure your activity passively, but also encourage good behavior. When working from home, it’s easier to become even more sedentary, with all work activities happening in a single room, and relaxing is often done within sight of that spot.

Social aspects of this should be prioritized -- to help connect and encourage people to stay active. Positive peer pressure through automatic sharing of your activity means that people aren’t able to hide, and we can hold each other accountable for good habits. Integration with social platforms should be seen as a way of amplifying the reach, not diluting the brand by leaving the walled garden you may have wanted to create.

It’s A Matter Of Accessibility

It’s certain that any sort of discussion around the connected lifestyle should include at least one use case where the user is at home -- and how we should optimize for that scenario moving forward. This, outside of our current crisis, is a great way to create a more accessible app for those who are homebound all the time. When pursuing this use case, consider the following:

• Look at the home as a primary use location.

• Looking into letting users share their experience with friends remotely.

• Focus on experiences with a long duration.

As is often the case, building for one constraint leads to improvements for many. If we all push ourselves to make improvements, we can work toward a better tomorrow, whether isolated or not.

This article was originally published on Forbes.com

May 16, 2020

Retailers with limited or no online offering such as TJ Maxx, Ross, and Dollar General are at risk of becoming ‘irrelevant’ in a post-pandemic world, analysts say

  • A select group of brick and mortar retailers was defying the retail apocalypse before the pandemic hit and reporting quarter after quarter of strong sales growth despite having a limited or nonexistent online offering. 
  • These stores found a way to circumvent the threat of Amazon and e-commerce in general by offering an experience that couldn't easily be replicated online. 
  • Analysts say that the narrative has changed now and the pandemic could lead to a permanent shift in customers' shopping habits, putting any retailer without a strong ecommerce offering at greater risk. 

To read the rest of this article visit BusinessInsider.com

© 2020 Bottle Rocket. All Rights Reserved.