DEV Community: Mike Sedzielewski

Becoming an e-commerce architect: 12 API integration skills for developers

Mike Sedzielewski — Thu, 01 Feb 2024 11:34:12 +0000

Postman has published my article, which highlights key API integration skills essential for an e-commerce developer. The post presents a list of practices and techniques we’ve learned during the development of Voucherify and its integration with various systems, including other headless platforms and consumer-facing applications.

Contents:

Read the fancy manual
Check API version
Double-check update guarantees and caching
Favor using idempotent endpoints
Scan the data-retention policy
Examine API error handling
Meet an API guardian: the rate limiter
Map out the way from migration to production
Master webhooks
Explore pre-built integrations
Detect downtime with status monitoring
Event-driven architecture and further reading

Maximizing Customer Loyalty with CDP-Powered Incentives

Mike Sedzielewski — Fri, 01 Sep 2023 13:26:41 +0000

It’s the twenties and the market circumstances made brands revisit loyalty programs. Privacy regulations, post-pandemic habits, and chain supply breakdowns caused a shockwave of changes to how digital teams design CLV schemes.

It might be hard to surf this wave without spending money on software. Connecting zero-party data, new customer experiences and touchpoints, and the whole ecommerce backend with the reward campaigns requires tasking a number of coders to glue it all together.

There’s a way to make the Gantt chart for your customer lifetime value projects shorter, though. It’s promo codes. Although they sound easy, they can become a pain when your scale grows. Fortunately, an integration of CDP and a Promotion Engine lets you embrace promo codes and forge a loyalty strategy without taxing your dev team too much.

Beyond the public codes — promo code types and their purpose

One of the Big 4 consultancy firms was tasked with finding out why “earn and burn” loyalty programs fail. They surveyed customers and came up with three reasons:

It took too long to earn points or rewards.
Rewards were irrelevant.
Too many notifications caused confusion.

How to address it? Let’s engage customers with something easy to understand, easy to use, and, finally, evoking the feeling of being rewarded. Any ROI-guaranteed examples? No sir, you need to experiment your way to find the reward-customer-fit.

Now, what’s the most straightforward reward to start building loyalty? A promo code — easy to understand and easy to use. Let’s see how we can make it more relevant with customer preferences stored in your CDP.

Iteration #1 — public promo codes

We have a blank checkout view. Let’s display “BLCKFRDY” on top of your your web/mobile app. It’s the simplest site-wide promo code, but is there any way to get it more personal? A pipeline between CDP and a Promotion Engine might help you pave the way.

The setup gives you a way to modify promo code experience depending on customer preferences. A product manager now gets a palette with three types of conditions:

Soft — showing or hiding promotions depending on one (or more) customer preferences.
Hard — making promotions exclusive only to a selected segments.
Dynamic — making promotions better (or less attractive) for some customers.

Let’s see some real-world variants we’ve seen in recent years.

With the CDP x Promotion Engine pipeline in place, building promotions take only several clicks to roll-out. Changing eligibility conditions or rolling them back is also a matter of selecting different attributes. This makes the public promo codes a scalable marketing tool — you can introduce new campaigns in days or even hours.

Iteration #2 — bulk codes

But sometimes public codes are not enough. Perhaps you want to be more selective when it comes to promotion eligibility (e.g., one-off “sorry” coupons handled by the customer support team). Or, you want to track marketing channels with higher granularity (e.g. exclusive anniversary discounts offered to “premium” members only via the app). Or, spinning a referral program by equipping your customers with a code that works as a discount for new customers and servers as a referral measure at the same time.

All of these examples are proven tools for enticing customer loyalty so you might want to have them under your belt. Bulk promo codes give you that and more.

How does a CDP & Promotion Engine integration make it easier for digital teams? First, generating up to millions of codes and making them available to a customer profile is out-of-the-box. The only thing remaining is to figure out how to display the code to the customer (see the next section👇)

Second, while implementing code generation is a fun challenge to a seasoned developer, maintaining it is not. Devs don’t like to be interrupted with requests like: “can you disable “HAPPY10” for one day please?”. This is where the Promotion Engine shines with hundreds LUX.

The admin dashboard gives the control over the bulk codes back to the revenue/marketing/customer success teams. They can search, disable, track, monitor, redeem, and roll back codes on their own, with the user interface that favors revenue generation and security.

The best part? It’s easy to mix public and bulk codes to test original promo codes ideas, see how they entice loyalty — again all without distracting the development team.

🥡 Takeaways :

Instead of rolling out a full-blown point program, start with promo codes (public and bulk) to see how they impact customer loyalty.
To create, manage, and track promo codes, build a promotion engine.
Use customer attributes from CDP to define promo eligibility rules and see how they drive revenue.

Beyond the homepage — funnel-aware promotions

Ease of creating and managing promo codes isn’t the only benefit coming with a CDP-fed Promotion Engine. Even a generous incentive won’t work if it doesn’t end up in the right place. Imagine an endpoint which returns all valid promo codes for the logged-in user. What can you do with it?

You can start with personalizing discounts on the side-wide banners. Let’s step up the game by displaying personal incentives further in the funnel — product pages, category pages, checkout, popups are also great places to nudge customers. For example:

Show a product-page discount only to customers who went dormant.
Reward them with a one-off code for leaving a review of a product.
Give a one-off promo code to the first-time customers, right after the purchase.
Display a time-limited promotion next to the cart only to the geofenced customers.
Or a classic one — show a last-resort cart abandonment discount.

But the true power comes when you feed your promotion system with the current cart structure. Then the branches of the promotional rules tree grow tenfold. With this in place, your promotional mix gets new knobs that allow you to control how much margin you can spend, or should I say invest, in your campaigns.

While most ecommerce allow you to define a minimum amount to make a promotion work, a flexible Promotion Engine can go way beyond that. The endpoint returning all valid codes for the logged-in user can now return product- and volume-specific discounts such as:

Buy product X to get Y with 50% off.
Get 10% off with $100 spend, make it 15% with $200.
Discount the cheapest product in the cart.
If you buy 10 SKUs, give one free.
Add a free gift, when buying something from the X category.

Finally, you can interweave customer segments with OR and AND like this one:

The code ARABICA-LVRS is displayed only on the “arabica coffee” category page, works only for selected SKUS and gives $10 off to new customers, but $5 to others.

Want a real promo scenario?

Carsome uses a mix of promotional rules to drive car sales based on customer activity and the stock information. The longer a car stays in the parking lot the worse it’s for the business. Carsome uses this information together with a tight CDP integration. The system watches out for user behaviour (car browsed, essential clicks, cart abandonment events), then these insights are put into a formula that defines what discount should be applied for a given shopping context.

This endpoint might work well for other promotional use cases, for example, reminders. Supposing your first-time customer received a discount for their next order via email (we’ll get to that later), you can show the same promo code on a flash banner once the user logs in to your app again.

You can take it to the next level by creating a customer wallet — a list of all active incentives the customer is entitled to. Showing redeemed offers is also worth considering as, with a bit of creativity, you can use it to paint a positive picture of your brand.

If you have plenty of ideas in your head by now, hold on, because we haven’t covered the best part yet — messaging.

🥡 Takeaways :

Showing promotions where the user is shopping increases the chances for using them.
Fine-grained promotional API helps you tie promotions to every funnel stage.
Adding the cart context to your promotion rules, enables you to roll out margin-sensitive incentives.
Promotion Engine that understands customer attributes and cart structure gives you utmost control over who gets a discount, when and what kind.

Beyond the website — email, SMS, and push notifications

For offline customers, promo codes are deadly effective call-to-actions. A CDP-powered Promotion Engine becomes a precision rifle that helps you target customers with personalized offers. It’s powerful and simple — the mechanism follows the “if-then” logic supplied with operators.

Technically, if a CDP tracks an event and notifies a Promotion Engine, it automatically creates a promo code according to the predefined conditions, then, if needed, notifies other systems about the offer. A few examples:

If a customer purchased an order, send them a re-engagement offer with email after 30 days.
If a customer clicked on a specific car AND it occupied the parking space for more than 6 months, double the discount and inform the customer with a push notification.
If a customer has a birthday today, show a 50% promo code for products up to $50 in the app, for the next 7 days.
If a customer’s total order amount exceeds $1000 OR the number of orders is greater than 10 AND she hasn’t redeemed BLACKFRIDAY code, send a webhook to Braze with a unique promo code.

These examples show how real-time events, common customer attributes, aggregated data, and interaction with previous offers managed by a Promotion Engine, can be used to trigger an incentive/reward workflow.

A caveat here — connecting promotions with messages on scale requires planning. Email/SMS deliverability has policies you do need to take into account. For example, your integration should be able to throttle and queue data to be sure every message ends up delivered, with all the {{placeholders}} replaced with the right values.

What you can do with a CDP + Promotion Engine + CRM tools + checkout system tightly integrated thanks to the API-first capabilities?

Pomelo, for one, used this approach to roll out a massive customer acquisition campaign together with a referral program. They built it in weeks and the project has been rewarded by Braze. We prepared a step-by-step guide for glueing four API-first tools to achieve a similar effect.

The list of use cases goes way beyond that. With tools like Braze’s Connected Content, you can wire personalized promotions to your messages by literally editing a message template.

Here’s a list of Braze x Voucherify Liquid examples presenting some promotional scenarios.

Building a wallet full of personalised incentives is one thing, but to move the needle with incentives you should make them easy-to-apply — we’ll zoom in on it now.

🥡 Takeaways :

Promotions can be effective when wired to your messaging platform.
Make sure to check how to work with a messaging queue in a scalable way.
Modern engagement platforms have nifty tools for incorporating data into messages without complex development work, check them out before you open your IDE.

Beyond the manual promo codes — promotions UX

Let’s sum up what we’ve achieved so far by connecting the CDP and the Promotion Engine.

We have generated coupons (both public and bulk), used customer attributes and cart structure to define their eligibility, and injected them in places and messages across the customer journey. A successful promo code redemption is the single most essential event in the whole process. Let’s see how we can make it easier for the customer.

Here’s a list of how you can shape your UI to put promo codes in motion:

Clearly state the timeframe of the promotion.
Automatically apply publicly available codes.
Create a sales compilation page (Remember wallet? How about the one for not-logged users?)
Enable filtering in your sales category.
Be clear about the restrictions of promotion upfront.
Leave the old price tag on.
Include coupon code fields as a core part of both the shopping cart and checkout pages.
For minimum-spend promotions, do the math for users and help them reach the spending target.
Display an error message for invalid coupon codes.
And many more.

Including these ideas into your UI already takes time. But if you sell through web and mobile, the development work doubles:

Listing used promo codes for specific customers
Showing discounts eligible to VIP customers only
Calculating total discount every time a product is added/removed from the cart

This is where a fine-grained REST API comes into play. SaaS Promotion Engines have endpoints for these use cases. You just model the backend once and connect the touchpoints.

Bonus : need ideas for the UI? Here’s a Figma Kit with the most common promotion and coupon components.

You can improve promo code experience even more. Remember our product-specific discount? You might be wondering why use codes for a “buy one, get one free” use case at all. And you’re right — with an advanced Promotion Engine, you can drop codes altogether, just show the promotion banner and make the discount auto-applied every time a cart is recalculated or the customer’s attributes are changed.

While auto-applied cart-level promotions working with customer attributes give leeway for next-level bundling, you need to know when to double down on a promotion and when to stop it. Promotion Engines have a few handy tools for that.

🥡 Takeaways :

Promotions are only as effective as their UX.
Building top promotion experience requires gazillion lines of front-end code, Promotion Engines make it easier serving predictable promotion backend.
Take a look at Coupon and Promotion Figma Kit to get inspiration for your frontend.
Why not to get rid of promo codes, when you can calculate the discount based on the shopping context — see if your Promotion Engine supports it.

(Not) beyond the budget — fraud and margin protection

It looks like we have everything ready to go after redemptions, higher sales, reengagement, you name it. We know how to counteract the enemy number one of promotional campaigns — lack of engagement. But nemesis number two is looming on the horizon — exceeding your margins and, simply, fraud.

Your Promotion Engine controls the discount eligibility based on the cart information and customer behaviour so you’re already in a better position to fight back. But there’s still some work to be done.

From the plethora of tools in your marketing toolbelt, promo codes are the family of “sharp knives” — ready for precise work but they carry the risk of hurting yourself. The biggest risks are losing money with too generous discounts and customers trying to abuse your offers.

Example? Let’s assume your offer is $10 off for the “arabica coffee” category. When the margin for some SKUs is less than the discount, you start losing money. Worse, imagine customers buy the whole stock of these particular SKUs.

How does a Promotion Engine protect you from the loss? There are three major features:

Dynamic discounts — the offer is modified based on a formula. In the case of Voucherify, it can include parameters such as an order amount, cheapest product price, or any custom attribute like margin.

You can soften the limits for specific segments e.g., your “loyal” tier, if you integrated CDP tightly with the rule engine.
Global safety caps — again, Voucherify can impose:
Redemption limits : per customer, per day, per customer per day/month, per given campaign, etc.
Budget limits : total discounted amount, total orders’ value, etc.
Promotion stacking — some promotions should be stacked in the specific order, some shouldn’t be stacked at all. A flexible Promotion Engine can work with such promotion dependencies.

🥡 Takeaways:

To experiment with codes with lesser fraud and promo misuse, you need to set up a safety net.
A Promotion Engine has dedicated features like parameterized discounts, budget limits, and stacking to prevent promotion loss.

Beyond the POC phase — when push comes to shove

Digital promotions, especially promo codes, look very tempting to be adapted. They have a hidden cost, though. It’s complexity and compliance. When designing your Promotion Engine, you should look far ahead of the POC phase. While the path onwards is different for every digital team, there are some common obstacles:

Marketer interface — the marketing team wants to change promotion conditions and touchpoints every day. No wonder, experimenting with the offer is what they get paid for. Enabling, disabling, searching, counting redemptions — they already call for some UI. Add approvals to the mix and you end up with a full-blown admin panel.
Internationalisation — if your pilot is successful, the next step is going abroad. Different currencies, labels, discount policies, or event product catalogs may break your promotion strategy in lots of tiny places.
Security & fraud — once in a while you can hear a story about the promo code that unlocked a once in a lifetime deal for way too many customers. Sometimes the loss exceeds a decade-long licence for a Promotion Engine. But you can expect more risk out there. Fraud and malicious actors in your team do happen too (not to mention data leaks). When running dozens or hundreds of promo code campaigns, investing in a coherent management suite with an audit log helps you sleep better.
Privacy — promo codes earned a special place in the SPAM prevention algorithms not without a reason. Even without GDPR implications, you want to be complicit with customers’ preferences. A good CDP & Promo Engine tandem respects people’s contact choice from the outset.
Scale — a well-crafted promo code can bring huge traffic to your store. We’ve seen this happen when one of our users ran a TV ad. Wise men put in manuscripts that the code optimization shouldn’t be your default. But when your checkout crashes during the peak, you just killed the viral campaign — the holy grail of every consumer-facing business.
Integration — finally, the code responsible for connecting promotions to other ecommerce tools, data sources, and customer touchpoints might be hard to maintain. Flexible and predictable API with good documentation will help you save time needed for building and testing data integrity and workflows.

🥡 Takeaways:

Non-functional requirements impact promotions too. Plan for them upfront, to pivot faster in the future 🚀

Beyond the promo codes — how about a full-blown loyalty program?

My friend plays in the symphonic orchestra. Apart from the full-size repertoire, they often play ensembles. Although I don’t plan to do so, I end up with a few tickets throughout the year. I love the experience of a small squad playing in a quaint place.

When you look at your customer loyalty strategy, I believe the same rules apply. People will often appreciate a truly personalized deal more than a virtual reward from an earn-and-burn loyalty program. But just like you can’t ignore the sound of philharmonic, the CDP-powered loyalty scheme is becoming a must for DTC brands.

How a CDP x Promotion Engine can help you build a loyalty scheme? By:

Connecting promotions and revenue-management initiatives to loyalty mechanisms.
Introducing points-plus-cash options to facilitate access to big-ticket rewards.
Granting non-monetary offerings such as: exclusive events, early access, or unique discoveries.‍
Paid membership where you can offer premium rewards that are too expensive to offer more broadly. Or, keep engagement with everyday discounts.‍
Cashback programs.
Give customers more options to redeem points, such as donating their points to a charity.

These use cases are even more complex software-wise. The good news is that when you battle test promo codes with CDP and a Promotion Engine, you have a solid setup for testing new incentives & reward programs in the next iterations.

Originally published at https://www.voucherify.io.

Amazon gift cards as referral program rewards with Incentives API & Voucherify

Mike Sedzielewski — Thu, 24 Aug 2023 08:20:51 +0000

For better or for worse Amazon Gift Cards have become a standard in incentivizing customers and employees. Amazon Incentives API provides an easy and secure way of generating gift cards in real-time. Let’s see how we can make them a part of a referral program run with Voucherify.

What you can build with Amazon Incentives API

The primary feature of the Amazon Incentives API is to create virtual Amazon gift cards in real-time. But it enables a bunch of other interesting digital incentive scenarios too:

Login And Receive — recharge a new or existing customer’s Amazon account when they log in (Amazon Login SDK necessary).
Activate Physical Gift Cards — programmatically activate physical gift cards purchased in bulk earlier.
Product Vouchers — create a gift card for a specific product category only (specs controlled by Amazon here).

The API also provides some brick & mortar gift card activity capabilities, go to the docs to learn more.

In this tutorial we’re going to cover real-time digital gift card generation which is a more secure and more convenient method to use them as referral rewards to buying gift cards in bulk.

API & portal access

Only verified partners can access the Amazon Incentives API. Verified means that you have Amazon Incentives partner ID — this is different from AWS solution partner ID. You can get this by filling out this form https://www.amazon-incentives.com/api/contact-us (For the Polish marketplace I waited ~2 weeks but it was a holiday season.)

Then, you can go to Step 2 of the onboarding guide.

The first API call

Note : Here’s a Postman collection with all API calls used in this tutorial.

Let’s test the API by creating a fake gift card within their Sandbox environment. We need three keys to authenticate a request: credentials and partner ID we obtained in the previous step.

To get credentials, go to /gc/corp/account/keys/, select Sandbox and create new access keys.

As with every Amazon service, the first step is to locate the right endpoint and region. For the Polish marketplace, the URL to Amazon Gift Codes On Demand (AGCOD) is https://agcod-v2-eu-gamma.amazon.com and the region is eu-west-1. You can find the reference here.

Also, any request needs to be signed with Signature Version 4 algo. If you test the API with Postman, then you can configure it in the Authorization tab as shown below (apart from credentials, remember to provide the respective region and service name: AGCODService).

According to the spec, we need to send the following payload to the /CreateGiftCard endpoint.

<CreateGiftCardRequest>
  <creationRequestId>YourPartnerIDTSpecTest001</creationRequestId>
  <partnerId>YourPartnerID</partnerId>
  <value>
    <currencyCode>PLN</currencyCode>
    <amount>10.00</amount>
  </value>
</CreateGiftCardRequest>

Caveats :

currencyCode needs to match the currency set up in your Amazon Incentives API account.
creationRequestId needs to start with your partner id as a prefix.

By invoking the request, you should get something like this:

<CreateGiftCardResponse>
  <gcClaimCode>GVFW-Y9DWGW-K5BQ</gcClaimCode>
  <cardInfo>
    <value>
      <amount>10.0</amount>
      <currencyCode>PLN</currencyCode>
    </value>
    <cardStatus>Fulfilled</cardStatus>
  </cardInfo>
  <gcId>4510447105517016</gcId>
  <creationRequestId>YourPartnerIDTSpecTest001</creationRequestId>
  <gcExpirationDate>Sun Aug 21 21:59:59 UTC 2033</gcExpirationDate>
  <status>SUCCESS</status>
</CreateGiftCardResponse>

Status Fulfilled means that the gift card certificate stored in gcClaimCode is ready to be shipped to the customer.

The developer portal should now be showing this:

How to store gift cards

Actually, you don’t need to. The AGCOD CreateGiftCard operation is idempotent, so if the API receives more than one request with the same creationRequestId, only the first request will result in the creation of a new gift card, and all subsequent responses will return the same original gift card. They will not be treated as different transactions.

This means you can use your customer identifier (up to 40 alphanumeric chars) to differentiate gift cards. Keep in mind that the service is rate-limited with 10 requests per second.

You can also import gift card codes to Voucherify. Importing them as regular codes will be helpful to track Amazon gift cards along with other rewards. The other way is to store them in a custom field in the Customer object.

Testing & error handling

Because gift card API deals with money directly, your integration needs to be rock solid. Good news is that the AGCOD architects prepared a rock solid test plan for your integration. The error codes list is also well-documented.

Highlights :

In case of a mistake, you can cancel the gift card within 15 minutes after creation.
You can simulate returning the error by any endpoint by providing a specific error code as a creationRequestId, e.g. F3003 will result in the endpoint returning F300 InsufficientFunds.
Success response can be mocked by using mock code F0000.
Six seconds is the recommended timeout for the client side application.
If you suspect a bug at their end, the AGCOD team describes how and when they want to be bothered.

You can monitor the available funds with the portal (/gc/corp/payments/notifications/), where you can also set up alerts for low balance:

Or you can call /GetAvailableFunds, Sandbox will always return 0 though.

<GetAvailableFundsResponse>
  <availableFunds>
    <amount>0.0</amount>
    <currencyCode>PLN</currencyCode>
  </availableFunds>
  <timestamp>20230821T154205Z</timestamp>
  <status>SUCCESS</status>
</GetAvailableFundsResponse>

How to use Amazon Gift Cards in your referral program

Earlier this year, Taxfix, a prominent provider of tax filing services in Germany, introduced a two-sided referral program to increase their presence in the German market. Individuals who successfully referred their friends received Amazon gift cards as rewards. The Taxfix development team employed Voucherify and Braze to manage the program, and the operational process unfolded as follows:

By utilizing Voucherify, they set up a customized referral program that allowed them to reward successful referrers with Amazon gift cards and invited friends with -50% discount codes on their first tax return with Taxfix.. With every referral code application, Voucherify would send a webhook notification to the Taxfix system.

Next, they would call Amazon Incentives API to create rewards ($30 Amazon gift cards) for each successful referral.

The Taxfix team used Braze to divide their audience into different groups and prioritize those who were most engaged. They strategically encouraged these engaged users to refer more people by sending them push notifications and emails. The referral messages contained a deep link that took advocates to a specific view in the app, where they could find their personalized referral code.

So, to create an end-to-end referral reward experience, Taxfix:

Generated referral codes in Voucherify.
Defined the discount associated with the referral code.
Defined a successful referral event — using the referral code during signup.
Promoted referral program with Braze emails and push notifications including a deeplink to the referral view containing the referral code.
When a referral event occured, they sent a webhook to the Taxfix backend system.
Backend called the Amazon Incentives API to get a new gift card code and send it with a transactional email to the customer.

Scaling and improvements

The scenario covers only a single marketplace. If you want to create gift cards for more countries, you need to get a partner ID for each supported country.

You can think of other rewards and incentive campaigns, both digital and brick and mortar. For instance, you can use Product Vouchers to narrow down the gift scope to be applicable only to Education Assistance products or other good cause.

Another option is to replace Amazon gift cards with vouchers or discounts for your services. With Voucherify, you can manage digital gift cards and other incentives within one platform.

If you want to discuss options or get some help, drop me a line.

LTV developer

Mike Sedzielewski — Wed, 16 Aug 2023 09:51:06 +0000

The Onion reports that the interdisciplinary research group dedicated to the investigation of the Anthropocene (AWG) has agreed to name the last decade ‘The Great Mobilification.’ Scientists characterize the era by the overflow of mobile devices used to distract humanity from the pain of being.

Jokes aside, the distraction often takes the form of careless consumerism. Businesses that want a piece of this pie need to learn how to navigate the stream of distraction. They need to find a way to have the consumer pull over next to their offer, over and over again. This is impossible without technology and thus a developer.

Dealing with this scale requires somebody who knows how to engineer data in the business context. This includes building data workflows and taking care of data integrity. But the ultimate goal is to recognize data patterns quickly and use them to drive revenue (or customer lifetime value [LTV]).

I call this person an LTV developer.

There are three traits an LTV developer should have:

Data expert
Fluent with modern marketing APIs
Doesn’t follow the “I did not complete the computer science degree, only to talk to mere marketers” rule.

Because The Onion’s sources claim that developers prefer to abstract data away, favor open-source solutions and building from scratch, and don’t want to be bothered outside IDE, there’s a massive gap of the LTV dev on the market.

Now supposing you want to fill the gap and break the bank, how do you start? While I don’t have an obligatory visual roadmap yet, I find this piece by Andy Carvell useful to picture the key areas.

I’m also a lifelong believer that the best way to learn something is by doing. The following list provides hands-on developer tutorials from projects I’ve stumbled upon while building Voucherify and watching top digital teams that integrated our product.

📚LTV developer reading list

How to make martech POCs easier

Mike Sedzielewski — Mon, 14 Aug 2023 09:55:10 +0000

Creating POCs in marketing technology has become a lot easier. Especially for someone like me — an ex-programmer who last coded professionally 10 years ago. Recently I’ve found 3 things particularly helpful:

1) Developer-first platforms with predictable documentation, sandboxes, and transparent pricing so I don’t need to go through mundane “discovery sessions”

2) @Replit— an IDE from the “it just works” family. No time wasted on environment setup, true single-click hosting. Also, the repo forking is a hidden gem of Replit — you can share a repo with your team, they just change secrets, start dabbling on their own, and then they can deploy it right away. Finally, ghostwriter — Replit’s copilot alternative that helps me stay in the zone when I’m looking up CSS syntax.

3) @htmx_org — lets me skip a decade of JS ecosystem “advancements” to get some interactivity done. These might seem of little value to a true coder but for a busy solutions architect or a tech-savvy marketer, this is huge (as I’m getting older, I tend to cherish simple products that help me save my CPU ticks).

Here’s a recent showcase: https://fun-with-promo-codes.sedzia.repl.co This is a basic demo showing how to integrate @voucherifyio and @bannerbearHQ to generate visuals for parametrized promo codes like this:

BTW Bannerbear is a joy to work with — intuitive, smart defaults, easy to integrate with. Impressive feature set when you consider their headcount @yongfook.

You can find the repo here https://replit.com/@sedzia/Fun-with-promo-codes#readme.md

The Challenges of Managing Promo Codes: A Syntax.fm Case Study

Mike Sedzielewski — Mon, 14 Aug 2023 09:54:26 +0000

Developers keep asking me why you need a promo engine when you can implement it yourself in a flash. From now on, I’ll show them this — the last episode of the Syntax podcast, where @wesbos and@stolinski talk about the tech stack for Syntax x @getsentry giveaway campaign.

The last episode of the Syntax podcast:

The Syntax Giveaway Site - Codes, Bots, Tech Stack and More!

Truth be told, I stumbled upon this episode by accident. Everyday, I inject myself with dopamine by watching “Voucherify” being mentioned all over the internet (thanks Brand24). Not everyday, however, a 350k-followers-strong developer mentions your brand in his podcast.

When it happens, you drop everything you’ve been doing and listen to the whole episode. I did so and the content wasn’t disappointing!

Wes and Scott discuss their recent giveaway campaign:

They joined Sentry (a top platform btw, we’re using it in Voucherify) and decided to celebrate in the best possible way: by giving people some SWAG.

To get the SWAG, you had to find a promo code sprinkled around the internet to have it redeemed later on a website.

Syntax x Sentry Giveaways is one of these little, short-lived projects where you want to play with a new tech stack and Get Something Done in 2 hours tops. After all, it’s just 700 random codes representing: 600 t-shirts, 50 skate decks and 50 yeti ramblers.

But, even so, it highlights all the challenges with managing promo codes in a nutshell:

generating unique, hard-to-guess coupon codes — codes should be long enough to be brute-force-proof (to achieve this, Scott used our free code generator, hence the mention)
managing the code’s state (active, locked, used) and owner — no two users should get the same code (What if Wes and Scott want to publish a bulk of 10 codes at the same time? What if they wanted to release the locked codes 30 minutes before the show? How to make sure a single user gets only one code?)
supporting multiple promo code types (“premium” / “standard”) — some codes should carry a different deal than others
fraud protection — the system should be prepared for users who want to exploit it. (Wes claims some agents recruited their home-grown botnets to get the priceless SWAG 🤯. This caused a massive traffic spike (~1.6m requests), so Wes had to react in real-time by rolling out an in-memory cache to filter out malicious requests.)

In the end, a 2-hour-tops project turned into a few days of work for seasoned developers, a series of hotfixes to production, and significant traffic in the cloud.

I recommend listening to the whole podcast to get the full picture and some tasty insights on the tech stack Wes and Scott have chosen for the project (Vercel, Svetle, Prisma, PlanetScale, Sentry (sentry.io).

Compared to a regular ecommerce campaign, it’s just a tiny, one-off marketing campaign. If Syntax.fm would like to scale it in future, the number of challenges would increase proportionally. At least, this is what we’ve seen when working with customers over the years.

At Voucherify, we’ve been building an API-first promotion engine to help devs overcome these issues with just a few lines of codes (or 2 hours tops 🙃). We also wanted to give teams an admin panel to control promo codes without committing to prod for every business change. Finally, Voucherify is ready for scale and fraud — we handle millions of code validations a day, we can rate-limit requests from a given IP address, you can stop a campaign when you hit your targets, and many more.

Decoding Commercetools Integration: A Peek Behind the Scenes

Mike Sedzielewski — Fri, 11 Aug 2023 15:06:26 +0000

This week Voucherify announced the commercetools connector. Integrating with another MACH tool gave us a unique chance to assess our product. By using APIs for a concrete use case, we could explore two POVs:

👉 What we can learn from MACH Alliance founders & leaders

👉 Is our API as dev-friendly as we want it to be?

Re 1) I talked to our devs about what they like about CT API. Among other things, the API Extension model was praised as “webhooks on steroids’’. Unlike webhooks, the synchronous and time-sensitive nature of API Extension makes it more predictable to work with (and boy we have been struggling with some pain-in-the-neck webhook mechanisms for some time).

The flexibility of this model and the requests chaining policy are also well thought of. You can do pretty much everything with an active order and pass all the relevant info further to subsequent call-outs.

commercetools API has some learning curve for sure, but once you grasp the basics and install the SDK you don’t need docs on the side to understand what’s in the “cart” and other objects passed with a request. When you add to it a CLI task that registers a local ngrok instance as a target endpoint for API Extensions, you — as Michał Moczulski puts it — “forget you’re working with external SaaS.”

Hats off to Kelly Goetsch and the team 👌

Re 2) The connector highlighted some gaps in our docs and SDKs. One thing that was clearly missing are sequence diagrams showing the order of API calls (like this one 👇)

BTW I learned about mermaid (https://mermaid.js.org/#/) which gives you grammar for building diagrams in your editor (and github can render it right away). Cool thing for automating product marketing too.

As for the connector itself, it’s open source so you can see how we implemented a few unique discounting features such as applying many promo codes/gift cards/etc at the same time.

But our integration team (Marcin Ślęzak, Tomasz Łochmańczyk, Michał Moczulski) is pushing new features. If you want to stay updated, star ⭐️ the repo on Github or join our Slack channel.

Links:

https://github.com/voucherifyio/commerce-tools-integration

https://community.voucherify.io/

How to Fast-track a Referral Program with Voucherify, Segment, Braze, and Branch?

Mike Sedzielewski — Thu, 10 Aug 2023 10:13:17 +0000

Referral programs have long been hailed as one of the most effective marketing strategies to acquire new customers, increase customer loyalty, and boost revenue. However, running a successful referral program requires careful planning, execution, and the right set of tools to achieve optimal results. In today’s fast-paced digital landscape, leveraging the power of technology and automation is crucial to maximize the potential of your referral program.

In this post, we will explore how you can fast-track your referral program using the powerful combination of Voucherify, Segment, Braze, and Branch. These four cutting-edge platforms offer an integrated solution to build your referral campaigns in days. In this guide, I will recreate the success story of Pomelo Fashion and their award-winning low-code referral campaign.

What were the rules of Pomelo’s referral program?

Pomelo Fashion created a highly personalized messaging experience by:

Streaming user data into Segment.
Creating relevant referral messages in Braze.
Using Branch deeplinks to ensure that users land on the app page & app store.
Leveraging Voucherify to deliver personalized messages and manage the referral codes.

Pomelo launched a two-sided referral program which rewarded both the advocate and their friends. When it comes to the promotional logic, several requirements had to be met to ensure that the campaign drives customer acquisition while preventing referral fraud and misuse:

Friend is not an existing Pomelo customer.
Friend uses advocate’s code to make their first Pomelo purchase.
Friend gets 200 THB off their purchase.
Advocate gets 200 THB coupon sent to their account EVERY TIME a new friend becomes a customer.
Friends referrals should work on both web and mobile channels.

But the real difficulty had to do with Pomelo’s scale. As an industry leader, Pomelo serves millions of customers in a dozen different countries. The real challenge was to launch, and more importantly, maintain the marketing agility of the referral campaign across markets and teams in a limited time frame for launching the campaign.

API-based building blocks of the referral campaign

Pomelo believes that with the right technology and marketing strategy, it’s possible to make personalization happen responsively, and at a massive scale.

As personalization today means crunching large volumes of customer data and synchronizing them across sparse systems and databases, Pomelo has become a power user of API-first platforms.

Here’s how they connected them to achieve:

Faster time-to-market.
Personalization flexibility.
Traffic spikes handled.

Now, let’s get our hands dirty recreating this setup. Before we continue, make sure you have these provided:

Voucherify, Braze, Branch, and Segment accounts (we need the API keys).
Postman (or any other tool allowing you to send and receive HTTP requests). We’re going to use it to simulate an app and backend exchanging messages.

Note: Follow these links to find API documentation of Voucherify, Segment, Braze_, and Branch.

Note: if you want to brush up on Postman and operating API-first platforms in general, you can visit our introductory article._

Note: here you can find the Postman collection of the requests we use in this tutorial.

Step 1 — Populate users across platforms (Segment)

Before we jump into the referral logic design, we need to ensure the basics are in place. The first thing on the list is the customer data integrity — we’ll make sure a customer gets identified properly on every platform.

Learn more : Customer segmentation — how to ensure data integrity?

Let’s imagine a new user signing up to our shop. We need to populate this information to Braze, Branch, and Voucherify to make the customer data actionable. That’s a perfect task for Segment. It provides a coherent abstraction for identifying customers, tracking their behavior on various touchpoints and distributing these data to relevant systems.

Off we go to Segment. We’ll create the first connection. The connection will receive data from an app or actually its backend (source) and will send it to Braze and Voucherify (destinations).

Learn more : How to use Segment custom attributes to personalize promotions?

Go to Sources , add a new source and choose HTTP API option. This allows you to fire HTTP requests to Segment’s severs from Postman. Name the source and optionally add labels to filter sources in the future.

Set up the Source in Segment

Let’s test the connection. Click on the source and copy your write key.

Copy the Write Key

Now, open Postman and create a new API request.

Change the method to POST.
Set URL tohttps://api.segment.io/v1/identify.‍
In the Authorization tab, select Basic Auth as TYPE and provide your Segment API key as Username.
Go to Body, select Raw and JSON. Place the following snippet in the body:

{
  "userId": "jim@dundermifflinpaper.com",
  "traits": {
    "email": "mike+jim@voucherify.io",
    "name": "Jim Halpert"
  }
}

For simplicity, we’re using emails as customer identifiers andemail aliases to test messages.

Authorize API connection

Exemplary API request

The customer data above serves as an example. To test the Segment API connection, you need to provide userID, email address, and customer name. Now SEND the request. When you see “success”: true, open Debugger in Segment. You should see a confirmation that your source has received data from Postman.

Check the API connection

Now that we have the source listening for requests, let’s pass them to Braze and Voucherify.

Add Voucherify as Destination

Go to Destinations and click Add Destination.
Select Voucherify from the Catalog and configure the integration.
Get your API keys and paste them into Segment. You can find your keys in theProject Settings in the Voucherify dashboard. Make sure the API URL corresponds with yourVoucherify settings.
Voucherify Application ID serves as Segment’s API Key. Voucherify Secret Key is Segment’s API Token.

Configure Voucherify integration

Next, switch on your destination and go to Event Tester. Select Identify as Event Type and Send Event. On the right hand side, you should see the confirmation that Voucherify has created a test user. Likewise, when you go to Customers in Voucherify dashboard, you should see the newly-created test user.

Test the Voucherify destination

Add Braze as Destination

Adding Braze destination is quite similar, here’s how the settings might look like (make sure your REST API key has User Data permissions). You will find the data you need in the App Settings in Braze.

Set up Braze destination

Now, the final task in this step is to activate the whole workflow. Ensure that both destinations are switched on, go back to Postman and hit SEND once again. Segment will receive the request and translate it in a way it’s digestible by Voucherify and Braze. As a result, the Jim Halpert should be visible on both platforms.

Test the Connection by sending an API request

Step 2 — Generate referral codes (Voucherify)

Now that we have our customers synced, let’s invite them to join the referral program. We’ll start off with generating referral codes with Voucherify. Begin by providing general details of your referral program.

Create a new Referral Codes campaign.
Define the name and the code pattern for our program (you might want to give a prefix and remove misleading characters like O, 5, I from referral codes).
Impose some time limits, they’re optional but usually of high importance for the success of a campaign.

Learn more : How to build a referral program?

Provide general details of your referral program

The third stage is essential. Here, we need to design on what conditions Voucherify should reward people. In our case, we want to give 200 THB to both advocate and new customer so we choose double-sided reward.

Now to the conversion event. By default, Voucherify awards advocates when their referral code getsredeemed. Sometimes, however, this isn’t enough to account for a successful referral. You might want to wait for the shipping or event return period. That’s why Voucherify enables you to define a custom event for this purpose (whenever Voucherify receives such an event via API, the valid referral is counted).

Set up the referral program workflow

We know when a customer gets awarded, but we’re still missing the actual reward. Proceed to the next screen to set it up. First, we define how we award referred friends — in our case it’s a discount coupon worth 200 THB.

Create referral reward for invited customers

At this point, we should think of some ground rules of the program. First, a friend should be referred only once. Second, we might want to increase the spend with minimal cart value for the referred customer’s first order. Finally, we can exclude customers from the program based on any attribute like location or payment method. Voucherify validation rules builder will help you achieve that with a simple editor.

Let’s skip Referrer Reward and Notifications steps (we’ll come back to them in a minute) and save the campaign. In this way, Voucherify will be ready to generate referral codes.

Step 3 — Assign referral codes to user profiles (Braze)

It’s time to actually invite customers to the referral program. First, let’s call the Segment identify again to have at least two users. Here is an exemplary API call:

{
  "userId": "michael@dundermifflinpaper.com",
  "traits": {
    "email": "mike+michael@voucherify.io",
    "name": "Michael Scott"
  }
}

Next, let’s create a Braze campaign that calls Voucherify to get a unique referral code and assigns it to every new user. To do so, we’ll use Connected Content.

Create a new email campaign.
Select your template and come up with an email copy.
Switch to HTML editor and paste the following snippet somewhere within the tag (preferably between
tags), substituting API credentials and the referral campaign identifier (get it from the URL in the Voucherify dashboard).
```
{% assign campaign_id = {{campaign.${api_id}}} %}
{% assign customer_id = {{${user_id}}} %}
{% assign source_id = campaign_id | append: customer_id %}
{% connected_content https://api.voucherify.io/v1/publications 
:method post 
:headers { "X-App-Id": "YOUR APP ID", "X-App-Token": "YOUR APP SECRET" } 
:body campaign=camp_YOUR_CAMPAIGN_ID&customer={{${user_id}}}&channel=Braze&source_id={{source_id}} 
:content_type application/json 
:save publication %}
```
- In the HTML editor, put {{publication.voucher.code}} where you want to display the code.
- Set up other parameters of the campaign and save it.
Use Braze Connected Content functionality
We’ve used Scheduled Delivery with immediate send-out. However, you can trigger the email send-out based on multiple events and attributes.
Once the campaign is launched, this happens:
- Voucherify generates a new unique referral code according to the pattern we defined.
- Voucherify publishes it to a user whose id is sent with Connected Content API call. (Once published, it won’t be used again for another user).
- Voucherify sends the new code back to Braze as a response to the API call.
- Braze puts the code in the right place and sends the email.
If everything worked as planned, we should receive emails and unique referral codes assigned to Jim and Michael in their Voucherify profiles.

Receive referral email from Braze

A new referral code is assigned to Jim
Bonus step — upload codes to user profiles in Braze
Thanks to Connected Content, Braze was able to send the assigned referral code in a message. However, it won’t be persisted in the Braze user profile. You might want to upload it to have it at your fingertips for further campaign engagement.
To achieve this, you can configure the referral campaign to send corresponding referral codes via Custom Attribute.
- Let’s edit our referral campaign in Voucherify.
- Go to Notifications and select Send referral code to the referrer.
- Scroll down and select Braze as a channel. (You’ll need a Braze API key with users.track permission enabled.)
- Provide the name of Custom Attribute that will store the referral code.
Set up referral program notifications
Save the campaign. From now on, every new Connected Call will populate the referral_code attribute of a user in Braze.

Use custom attributes to store referral codes
Step 4 — Create tiers for referrers (Voucherify)
Let’s wrap up the current setup. Thanks to Segment, every new user is synchronized with both Voucherify and Braze. Then, the active Braze campaign retrieves a unique referral code from Voucherify and sends it via email to the new user. The code is managed by Voucherify, it’s linked with the user and the promo engine treats it as a 200 THB off coupon for every new referred customer. You can validate the referral code to confirm this.
Create a new Postman request and call validate endpoint from Voucherify API.
- Select POST method and put the following URL: https://api.voucherify.io/v1/vouchers/{CODE}/validate replacing CODE with your referral code.
- Add X-App-Id and X-App-Token headers and fill it with Application ID and Secret Key respectively.
- Set Content-Type header to application/json.
- Set the following Body to simulate a friend trying to redeem the referral code and SEND.
```
{
    "customer" : {
        "source_id" : "pam@dundermifflinpaper.com"
    }
}
```
Voucherify should reply with the information about the referral code.

Test validating the referral code
What we’re still missing though is something that would move the needle — an actual incentive for advocates. Let’s give them 200 THB for every referred friend.
- Edit your referral campaign and go to Referrer rewards.
- Create the first and only tier which awards referrer every time referral event occurred. You can create many more to employ some gamification theme. Apart from the number of successful referrals you can add more validations rules, like location or budget to name a few examples.
Create a tier for referrer rewards
Go to Rewards and CREATE NEW REWARD. Our plan is to give a 200 THB coupon for every referral. Name your reward to help you reference it in reports (something like “200 THB off”) and click CREATE NEW CAMPAIGN. Here select Amount type coupons of 200THB value and SAVE. Now ADD REWARD to assign reward to your referral campaign.

Confirm the referral reward
The last step is to notify an advocate about the reward. To do so, we’ll send a reward coupon code to advocates profiles at Braze. Enable Braze channel and define how Voucherify should name the reward related Custom Attributes.

Notify customers about referral reward
Save the campaign and the Voucherify part is ready. It’s about time we tested what we’ve built so far end-to-end. We’ll simulate the scenario of Jim referring the service to his dear friend — Dwight. In effect:
- Dwight gets 200THB off of her first order.
- Jim gets a 200THB coupon reward.
- Dwight receives an invitation to referral program with a unique referral code.
Switch to Postman and follow these steps:
Dwight installs the app and creates an account — the backend detects a new signup — call Segment Identify request with the body below to notify Braze and Voucherify about a new signup. Go to dashboards in Voucherify and Braze to see if Dwight data got populated correctly.
```
{
  "userId": "dwight@dundermifflinpaper.com",
  "traits": {
    "email": "mike+dwight@voucherify.io",
    "name": "Dwight Schrute"
  }
}
```
Dwight uses the referral code at the checkout — the ecommerce engine needs to apply the code to the cart. Call Voucherify Redemption to validate the referral code and to calculate the discounted order price.
```
{
    "customer" : {
        "source_id" : "dwight@dundermifflinpaper.com"
    },
    "order": {
      "amount": 80000 // amount multiplied by 100 to handle decimals
    }
}
```
Redeem the referral code with Voucherify API
Dwight gets his first order delivered to the farm — the backend listens to the shipping status and notifies CRM platforms about the updates — call Segment Track Referral to notify that a successful referral should be counted.
```
{    
"userId":"dwight@dundermifflinpaper.com",    
"event":"referral",   
"referral":{  
"code":"torchie-MYRATKCP"    
}
}
```
When we look into the referral program dashboard, we should see two things:
- Jim’s referral code has been already used once (by Dwight).
- A newly generated code for Dwight.
Visit the dashboard to see referral codes status
When you visit Jim’s profile in Braze, you can see that he received his first referral reward coupon.

You can see the referral reward code in Braze
When you invite new users to the referral program again, Voucherify will generate Dwight’s referral code via Connected Content and send it to his profile in Braze.
The very last step is to notify Jim about the reward. The easiest way to achieve it is to create an action-based campaign which uses Change Custom Attribute Value trigger. So, whenever reward_coupon_code changes its value with successive reward notifications from Voucherify, Braze sends a message with the reward coupon code.
In a production environment, you might and should integrate in-app customer profiles with Voucherify to show their full promotional wallet, including referral code, statistics, and above all rewards. For the web version, you can use Voucherify pre-built cockpits.

Visit individual customer hub to see the referral score
Bonus step — Add more tiers (Voucherify)
If the campaign performs too well, you can easily add more tiers to gamify the referral frenzy and protect your budget. For example, you might want to send one reward for one referred customer, and then another one but only if an advocate earns at least five referred customers — so two rewards in total regardless of the number of successful referrals. To apply this to your program, just edit your campaign, go to tiers section and:
- Edit the original tier, so that number of Referred Customers is more than 0.
- Create another tier, and set the condition to Referred Customers is more than 5.
Build additional referral tiers
Step 5 — Onboarding with deeplinks (Branch)
The missing puzzle is how we can attribute app installs to our referral campaign and how to send newly registered users the referral deal. With our current setup, the advocate has to send a referral code to their friends. Then, they need to save it somehow to paste in during the checkout stage. What if we could modify the referral link in a way it lets the app store and apply the code automatically?
To achieve this goal, we need deeplinks. Many of you already use one of the deeplinking platforms, you can use it here for integrity. In our case, we’ll go with Branch.
While Braze x Branch integration hassome advanced goodies for branded deeplinking, this is beyond the scope of this tutorial. We’re going to uselong links to show how straightforward it is to attribute installations to our referral campaign and how to point new users to a specific view.
When our deeplink is clicked by a new user, Branch will redirect them to a corresponding place, either App Store, Google Store or a web page. Then, when the app is installed, the parameters that we pass with the URL, will be read by the Branch SDK on the mobile app. In this way, the app will be able to recognize the referral code and store it in the user’s profile. Here’s how our deeplink is constructed:
- + +
Let’s implement it with Branch:
- Open your Branch dashboard and go to Configuration.
- Provide the links to the stores and a fallback link in for the web view. (As we don’t use real apps in this example, we skipped stored links).
Configure Branch redirects
Scroll down to Link Domain and set up your domain. (Again, for simplicity we use default ones).

You can use default link domain to test the flow
Open Postman, create a new GET request and type the following long link:
g9xol.test-app.link/?~campaign=referral&code=torchie-MYRATKCP&$fallback=https%3A%2F%2Fshowcase.voucherify.io
Before we click SEND, let’s analyze each part of our long link:
- g9xol.test-app.link — our Branch domain (you can configure your custom one for better branding).
- ~campaign=referral — telling Branch how to attribute the click.
- code=torchie-MYRATKCP — Jim’s referral code.
- $fallback=https%3A%2F%2Fshowcase.voucherify.io — (optional) telling Branch where to redirect the user after click in the fallback mode (we’ve set up the primary mode in Branch dashboard).
Now, when you hit SEND, simulating a user clicking on the link, the request goes to Branch which will redirect the user to the right place.

Send a test API call to Branch
When you open Source and compare by campaign, you’ll see that the click was correctly attributed to our referral campaign.

Test Branch click attribution
Now, go back to the Braze referral invitation campaign and add our link to the message. In the URL, remember to replace Jim’s code with {{publication.voucher.code}} to ensure every signup gets their own unique code.
Step 6 — Manage your referral campaign
In these five steps, we’ve created a complete POC of a solid referral program. Thanks to powerful mar-tech tools, we were able to spin off a highly targeted referral campaign in hours. The API-first approach allowed us to outsource the backend part while still having flexibility over the mechanics of the referral calculation. What’s most important, with the collaboration between Braze, Segment, Branch and Voucherify you can enjoy 100% personalized, on-brand experiences with app and web customer touchpoints.
The best part? Lower development efforts required. Both of the implementation part and maintenance. With Voucherify, you can change the referral program conditions on your own. Think running A/B tests with limiting referrals per advocates or referrals in total, adding minimum spent value to the friend’s order, or excluding specific customers or whole segments from the program.
The final step is to define the requirements for your developers. Within a day or so, they should be able to translate our Postman requests into the production code (check out official SDKs). The initial launch might require some bulk customers sync and depending on your traffic you should consider the rate-limiting policies of the platforms — this is where the official API documentation comes in handy.
With Voucherify and your mar-tech stack you can launch many more personalized incentives. Visit our docs to learn what goodies come with our API, get our Postman collection, and happy hacking!

What's MACH and how it can make you 10x ecommerce developer

Mike Sedzielewski — Wed, 12 Oct 2022 08:11:43 +0000

If you develop ecommerce solutions and think of steering your career towards software architecture, you might want to learn about this new trend. It’s about enterprise software aimed at improving the productivity of digital teams. Sounds odd? Meet MACH (Microservices based, API-first, Cloud-native SaaS and Headless). While it might sound like a bundle of buzzwords, it's all about bringing better developer experience into ecommerce projects, helping you ship faster.

Microservices? It's so 2010s

The history of MACH dates back to the 2010s but it wasn’t until 2020 when it got a name and caught the attention ofmainstream brands. What's this fuss about? In early 2010, Twilio and Stripe earned developers' love with their API-centric approach. Up-to-date documentation, code samples for every major platform, and free tiers to test the solution inside out changed the way developers produce commerce software. It didn't take long until a few business-oriented engineers noticed that this approach can make a dent in the core ecommerce areas.

Before I give you a hint what’s so special about MACH tools, a disclaimer: everybody that have been in the industry long enough realize that devtools revolve around the perpetual hype cycle: bright and shiny; startups use it -> claimed by an enterprise -> consultants necessary for maintenance -> downfall but still in use ->memes emerge.

MACH tools will follow this path no matter what. But the good news is these tools have just entered the 2nd phase. This means they still have a long way ahead but, at the same, they've grown with enterprise features so that they can be recommended in the corporate environment too.

So, why MACH tools now? Well, it's about speed. In ecommerce, speed wins the market. As more and more commerce happens online, the more focus is put on helping digital teams roll out and test new commerce experiences (or devise new ways of monetizing our attention).

Fewer ASAPs with better APIs

How does MACH help with the speed of the digital team? I didn't use "digital team" without a reason. MACH tools make work easier for both developers and ecommerce operators (marketers, sales, support, logistics).

First of all developers are given dozens of standalone, battle-tested features enclosed in API endpoints. On one hand, they free up a substantial amount of time – there are building blocks who took a year for a whole team to complete, polish, and document its API request/response. On the other, with the headless approach you get to decide how the UI works. In a nutshell, it's a middle ground between build and buy.

What about operators? In fact, they are the first-class commerce software users. Sometimes they use it more often than consumers. Internal tools tend to get worse UX and support than software running the pixel-perfect checkout view. MACH tools address this case with operator-friendly admin panels/dashboards. They're optimised and documented for marketing/support/inventory agents so they can get their jobs done.

When you think about it, it's actually the devs who benefit twice. They get business logic out of the box (with the freedom to update frontend with the new framework that dethroned legacy stuff from the last year). But they also get fewer meetings and ASAP requests from the marketing team because it all can be managed within a dedicated UI. And, in case of questions, there’s always the vendor support teams🙋 What's not to like about it?

Finally, the SRE teams have a reason to be happy too. Headless platforms brag about being Black Friday-ready throughout the whole year. Because MACH platforms serve API requests across the globe they expect fans to be spinning faster for some TV ad in Big Brother all the time. When building software from scratch, there's always someone asking: but will it scale? In the MACH world, this is guaranteed from day one.

OK, show me examples

Every software platform that lives long enough to become enterprise-grade develops an allergy to explaining things in simple terms. Benefits, buzzwords, battlestar galactica… the webpage overgrows with terms aimed at making the brand look bigger and showing that it’s gonna fix all issues the next day you buy. In my opinion, most of the MACH companies don't go this route.

As dev-focused tools, they explain their offer with the IO-centric approach. If the product homepage still looks too vague for you, you can always turn to the API references to find your answer in JSON.

To give you a sneak peek into what commerce building blocks are already on the market, I prepared TLDR versions of each MACH member. Inspired by AWS in Plain English, I’ve gone through the MACH library and here it is – a short, ™️-less, and, not-so-serious explanation of MACH members.

(Note: the list isn't exhaustive because every quarter dozens of new headless SaaS are launched. Here I focused on those that were qualified by the ecommerce veterans formed as MACH tech council.)

Algolia, constructor.io

One line explanation: Typo-tolerant product search with instant results.

Use this to: Help shoppers find products with autocomplete and immediate search results filtered and designed according to customer attributes.

It’s like: Amazon search, but prettier.

Amplience

It’s like: Contentful/Contentstack/Storyblok x Cloudinary👇

Bigcommerce Enterprise

One line explanation: Headless version of Bigcommerce with extra hosting, security, and support options.

Use this to: Manage orders, carts and product catalog when you’re a mid-market to enterprise company.

It’s like: Shopify Plus but Bigcommerce was first to use “headless”.

Bluestone PIM

One line explanation: CMS structured as a product catalog tree which synchronizes with marketplaces.

Use this to: Synchronize product information and prices across any sales channel.

It’s like: Product_Catalog_August2021_final.xlsx shared on Dropbox that sends changes to marketplaces on every “Save”.

Bold Commerce

One line explanation: SDKs for building checkout pages with support for subscriptions and bundling.

Use this to: Test which checkout flow works best for different devices, customer segments, pricing rules, and compliance requirements on top of Shopify, Bigcommerce, or commercetools.

It’s like: If Shopify, Bigcommerce, or commercetools had an extra team to untangle checkout UI complexity.

Cloudinary

One line explanation: Image and video storage with transformation/transcoding features and CDN.

Use this to: Store and modify media for your product pages.

It’s like: Imagemagick and ffmpeg in the cloud, with support.

Commercetools

One line explanation: All-around ecommerce platform with an extendable data model.

Use this to: Manage orders, carts, and product catalog with geographical and performance scalability.

It’s like: Developer-friendly Magento in the cloud, minus the front-end.

Contentful & Contentstack & Storyblok

One line explanation: Mobile-friendly CMS.

Use this to: Store and update content of your product pages with device, geographical, and performance scalability.

It’s like: Wordpress but works fine with mobile apps, even under really heavy traffic.

enactor,fluentcommerce & NewStore

One line explanation: Inventory tracking with a graphical editor for order routing and mobile POS.

Use this to: Track product availability and orders across multiple stores, with the support for online and offline fulfilment.

It’s like: Your fulfilment team’s checklist looks like this:

Vuestorefront

One line explanation: Components for building UI on top of headless commerce platforms.

Use this to: Build internationalized, mobile-friendly, single-page shop storefronts.

It’s like: Your storefront is finally taken care of by a horde of senior frontend developers.

Occtoo

One line explanation: Customer data platform.

Use this to: Connect several ecommerce systems to exchange data in real-time.

It’s like: Ecommerce-focused Segment.

Personify XP

One line explanation: A script replacing parts of the website according to visitor attributes.

Use this to: Insert more relevant content to a visitor clicking in your shop.

It’s like: A proven hierarchy of 'ifs' you can use to make your product page more personalized to a visitor.

poq

One line explanation: Native mobile apps builder with a drag & drop editor.

Use this to: Build a mobile app for your shop.

It’s like: Every shopping app looks the same, so why not replace mobile software developers with software itself?

uniform

One line explanation: A UI-controlled script that replaces parts of a website according to visitor attributes.

Use this to: Make static websites dynamic again.

It’s like: A jamstack version of Optimizely.

Voucherify & Talon.one

One line explanation: Rules engine for incentives and rewards with an admin panel.

Use this to: Control who and when can get a discount or loyalty points.

It’s like: Your marketer can deactivate this one coupon code without waiting for the next spring.

VTEX

One line explanation: All-around ecommerce platform with a great number of API endpoints for particular sectors.

Use this to: Run ecommerce with geographical, performance, vertical and [put yours] scalability.

It’s like: You merged all other MACH Alliance members into the MEGAMACH platform.

Fine, show me the code

If you want close-to-real world examples, why not take a look at winner repos of the recent hackathon organised by MACH.

The best way to learn how MACH speeds up developer productivity (as well as where it becomes a pain in the neck) is to follow folks who have maintained MACH-based solutions for a while now (MACH advocates) or meet them at one of MACH events. And if you can’t, you can always turn the MACH radio on.

How we moved from MongoDB to Postgres without downtime and cut our costs by 30%

Mike Sedzielewski — Thu, 06 May 2021 10:11:44 +0000

Voucherify was born in 2015 as a weekend hackathon project run by our small-scale software house, rspective. Initially, it was backed up by a MongoDB database. Truth be told, this choice was random – it was the most common database we used in our projects. We already had some experience with it so Mongo was a pretty natural component at that stage. However, as Voucherify's scale grew, we’ve added a second database – PostgreSQL – that seemed to be more suitable for the upcoming features. Then for some time we kept part of our data in Mongo, and the other part in Postgres, until the day we decided to move it all to Postgres.

When we started out, we already had around five years of data collected, spread around multiple database instances, located on three continents, each dedicated to a different Voucherify cluster. Millions of voucher codes that could be updated anytime. Around a terabyte of constantly changing data. And to make matters worse, a lot of code had to be prepared for the upcoming breaking change. If presented on a timeline, we spent three months rewriting and testing new code and next three months migrating all the data.

Why then go through all this trouble? We had two valid reasons to do that.

First of all, as you can easily imagine, maintaining two different database types creates a cascade effect of doubled codebase, paradigms and concepts you have to keep in mind while adding new features. It was also the source of problems with the initial setup followed by issues popping up randomly (usually, on Friday afternoons). If one of them looks redundant, then all these issues sum up and cause tension and frustration in the engineering team.

Secondly, Compose – a SaaS platform serving MongoDB that we were using, was very expensive in comparison to alternatives. It became a significant percentage of our monthly expenses. Additionally, we were not satisfied with the quality of the support we got. Sometimes response delays could be as long as several days. In some cases, the only offered solution was to restart the database, with no good explanation of why the weird stuff happened in the first place or whether they plan to fix that in the future.

To succeed with the migration and maintain platform stability when the traffic was high, we split it into a couple of tasks – each corresponding to a different entity. Most of them were easy migrations of relatively small chunks of data that was updated rarely. Each of these tasks has its own story, but this article is going to tell the story of the last task. It was about two core entities – vouchers and campaigns – that serve as primary objects in Voucherify API. As you can imagine, these were kept in Mongo for the longest. You could say that the core of our system was built around the database that had to be replaced.

We used AWS’s Database Migration Service to help us with migration. The primary motivation was to reduce the time of preparing the setup for the migration tool, by relying on a SaaS solution tested by hundreds of developers already.

We decided to create new temporary tables for each Mongo collection, and somehow safely merge them with production tables in the next steps. The PostgreSQL database has a nice feature that helped us, called table inheritance. It gave us a possibility to join two tables together in a hierarchical order to obtain a parent table having multiple independent child tables.

Here is what we did:

Sanity check of data in MongoDB.
Creating child tables with Postgres Inheritance.
Applying transform triggers.
Running Amazon Database Migration Service scripts.
Sanity check of data in child tables.
Moving “deleted” data from child to parent table.
Switching applications logic to use Postgres.
Anomaly detection.
Moving “active’ data from child to parent table.
Stopping and removing DMS tasks.

Read the whole post on our blog

How to use the cloud to build applications faster

Mike Sedzielewski — Tue, 06 Nov 2018 16:32:28 +0000

It seems like everybody wants their apps to run faster and faster. Hundreds of posts on application performance are published every year. But articles about creating applications quickly are pretty rare to find. That’s a pity because when push comes to shove this is what counts for business. Development productivity is the knowledge which allows you to tell a CTO/tech lead apart from a regular developer. Let’s talk about it then. In this post, we describe 3 modern software development approaches you can use to deliver features like a well-oiled assembly line.

Speed of delivery is key to winning in the market. The time of “build -> launch -> measure & adapt” cycle is a key metric for the majority of software produced today. That’s why today’s engineering teams come up with more and more sophisticated tools and practices to reduce time to ship. These include continuous deployment processes, build automation tools, coding guidelines, and static code analysis tools. All of this to create a controllable environment for smooth software delivery lifecycle with dozens of coders.

Nonetheless, while these artifacts are useful, it seems like some teams focus too much on optimizing them. Refining build pipelines or developer environments doesn’t always lead to cutting time to market — sometimes it can even have a negative impact on delivery speed.

Our experience shows that turning your focus to 2 aspects of software development lifecycle brings better results to shipping speed. These are:

achieving code simplicity
building a rapid feedback setup

While they can be approached from many angles, I’d like to focus on one in particular — API-first SaaS platforms.

API-first building blocks instead of your clunky POC

Let’s start with a short intro of these solutions. API-based or API-first platforms provide a particular piece of functionality wrapped with an API that is easy to integrate with. You can use these endpoints to implement a well-adapted solution without the need of starting from scratch.

There are a few hard-to-miss features of API-based solutions:

the main business value comes from the API and webhooks, and the user interface (if there is any) plays a secondary role, and is used mostly to administer the account
they provide a thorough developer documentation
they have dedicated teams to take care of security and availability

Profit? The business gets the speed and flexibility at the same time. And savings of course. As a user of such a service, you usually pay for the actual usage, the number of requests for example.

So what’s that got to do with 2 goals of fast delivery we’ve mentioned?

The first one is straightforward. You just need fewer lines of code to implement the solution the task is about. Sure, there’s some learning curve at the beginning, but overall the time you spend on familiarizing yourself with a new API — usually with decent documentation and examples — is shorter than what it takes to create a feature with a regular “trial and error” approach.

Unless you’re a seasoned developer in a particular area, the solution provided by the platform will be more robust. And even if there are some errors or confusion, the support team will help you handle the case.

The second goal naturally stems from the first one. If you implement the feature quicker, then you can test it with users sooner (thanks Sherlock). But to gather feedback properly, you also need a way to collect and visualize data for the metric the business is after. API-based platforms might be helpful here again because, usually, they provide detailed usage statistics (also available through API) and sometimes even whole reporting modules.

So all in all, putting a feature together with API-based platforms is a better approach than your quick-and-dirty proof of concept.

OK, let’s see an example.

Case: imagine an early stage but rapidly growing online marketplace which connects suppliers and customers. The process of matching ones with the others is done manually by operations agents. With increasing traffic, the company needs more and more agents to process the orders. They decide to ask the tech team to automate this activity. Matching takes into account several parameters: time slot, location, customer preferences, supplier category, supplier rank, and of course the amount of money they make on every order.

Now the goal of the project project is to reduce the time of agents while keeping the profitability of the matching function.

The first idea which came from the management was to commission a machine learning algorithm and connect it to the CRM platform. But the CTO was skeptical. He knew it would be an expensive ride. Ultimately, he was afraid it would take a while to develop a solution which yields results similar or better than agents. He forced an alternative approach which focused on unburdening the operations team in short term.

He analyzed the data and found out some patterns. Then, he decided to replace the human factor with SMS. The engine analysed incoming orders and sent the “Do you accept this XYZ job? Yes/No” message to several suppliers. The process sent SMSes according to a pattern including aforementioned parameters. Whoever accepted first, won the order.

This was quick to implement and worked out very well! Of course, the solution didn’t cover 100% of cases but it significantly reduced the ops team effort by 60%, gaining more resources for other operational tasks. It was a matter of days, not weeks or months.

Now the key part is that the quick delivery wouldn’t have taken place without the help of API-first platforms.

First, instead of building the SMS gateway, they team went for Twilio. Second, instead of implementing a cron-like functionality, they used EasyCron. Third, to calculate geo-distances, they tapped into Google Maps API. The whole solution was basically just a loop and a bunch of ifs, and several HTTP requests.

In summary, they quickly managed to get an important feature live and achieved business goals in no time. On top of that, the code responsible for this functionality was super simple and thus open for modifications (which they did later — automating 90% of order allocation).

But API-first platforms have their caveats too:

The most important thing you need to verify as part of your SaaS research is limits. API-first vendors impose thresholds to simply make money as well as to protect their service from unexpectedly high traffic. Make sure then the limits are aligned with your use case budget.
The second is a fallback plan — depending on the impact on the business, your system should be accordingly prepared for the outage either of a vendor’s platform or yours. Features like system down/maintenance alerts and webhooks which repeat failed requests help in such cases.
Make sure the provider you want entrust offers a support policy which goes along with your business case.
No bigger company will allow for integration with a 3rd party system if it doesn’t provide enterprise-grade features. Prepare a list of what’s required in your org.

Recommended reading :

Business apps is copy-and-paste-and-change-one-thing

A seasoned business application developer would say that business software products are more or less copy’n’paste. This has certainly been a leitmotif for Salesforce founders. Having this in mind, they’ve built a CRM platform which powers hundreds of thousands business apps around the world. So why has Salesforce managed to attract so many customers and why are we talking about this at all?

Salesforce started as a SaaS CRM solution. They were one of the first players on the market and their sales pitch back then was “NO SOFTWARE”. They aimed at attracting companies trying to automate their sales processes which were fed up with sluggish on-premise software. Their SaaS offer turned up to be a massive success.

But fast-forward to the second decade of the 21st century, we can see that Salesforce is not “NO SOFTWARE” anymore. Actually today, they claim that 50% of their profits comes from the usage of Salesforce API. What happened to “NO SOFTWARE” then?

Well, SF realized that although 80% of CRM application works the same, companies still needs software services to integrate other systems and customize data flow.

With this observation, they started to give companies the ability to configure the setup. It started off with custom fields, simple triggers, lookups, reports etc. These capabilities turned out to be in high demand, so the SF team decided to push forward in this direction.

They extended configuration options by adding:

programmable software environment with their proprietary language called APEX
created Lightning UI framework to create new views right in Salesforce
exposed API and webhooks-like functionality to connect external systems

In other words — they bet on software.

With this setup, you can automate helluva lot of sales processes. But it’s not only about sales. Through acquisitions and development, SF can now cover various departments making the whole business tick. The best thing about that? Developer productivity.

With a handful of tools, a single experienced SF developer can provide more value than a dozen of coders building a business app from zero.

And we’ve been there. Remember the fast-growing online marketplace company from the previous example? They bet on Salesforce almost from day one. After 3 months of running on Google Spreadsheets, they transferred their small-back-then departments to SF and never regretted this decision. In hindsight, SF allowed them to grow for the next 3 years. How did it work?

Salesforce was treated as a single source of truth, there was no database other than that. Part of functionality was developed with APEX and Lightning right in Salesforce and the other part using external system in Node.js connected with API. By connecting other API-based platforms through the API, they achieved very high developer productivity.

The other Salesforce features that led to high speed in software delivery:

When the company change the business model and, in turn, the database model, they could react super quickly by exporting data through Data Loader, rearranging them in Excel(!), and putting them safely (with the right format) back to Salesforce.
Whenever they were hitting limits, they did cost-benefit analysis on how to proceed with a feature — either to extend quota or to figure out a work around. For example, when data analytics queries started to utilize a large part of quota, they replicated the internal database to a Postgresql instance (through Heroku Connect) and changed the data source accordingly.
Whenever the business asked for a new feature, there was a high chance that AppExchange marketplace had some solution

But Salesforce is not all bells and whistles. Similarly to MS Sharepoint, the SF developer experience leaves a lot to be desired. Cumbersome IDE, poor support for multi-developer environments, poor source control technologies integration, long deployments — this all makes a software developer cringe. Fortunately, they’ve noticed their bad and have been fixing it with Salesforce DX.

Recommended reading:

Quick and not-so-dirty internal apps

Excel supports (too) many business processes across departments. Most of them are fed up with data with a regularly scheduled database export, some of them are even connected to a DB directly. Although Excel is a real powerhouse for various analytics, both off-hand charts and robust year-to-year summaries, it’s still one of the most criticized approach to business intelligence. Reason? It’s error-prone, it’s hard to track changes, and finally, sharing among users and roles is hindered.

You can of course use 2 previous approaches to replace them, but often either it’s not worth the effort or the new solution won’t be flexible enough. So, what can a CTO do in this case?

One way forward is to tap into SaaS like Metabase, Redash or Retool. What they offer is the controllable access to your database with out-of-the-box reporting and charting capabilities. Their user interface is intuitive and less error-prone than a regular spreadsheet. And when Excel is simply used as a list online, you can replace it with tools that are build just for this reason, such as Airtable or more advanced Smartsheet.

Whatever tool you use, in most cases it’ll be way faster to mimic or even overtake Excel than in case you’ve decided to implement it from scratch. Of course, you need to consider initial user onboarding effort, but it’s worthwhile because this approach will increase the productivity of internal apps users in the long run.

The cloud is here, use it

Your role as a CTO/tech lead/even regular developer is to solve business problems with the best yet the most cost-effective tools you find out there. Today, SaaS tools have become mature enough and developer-friendly to put them into your toolbelt. Depending on your decision-making level in your company and the problem specifics, you can outsource the solution to appropriate flavour of SaaS. You’ll get simpler and maintainable code which will lead to faster feature experiments, and ultimately, to better productivity in your team — hopefully better rewarded by the management :)

/Photo by Egor Lyfar

Hunting down large-scale Node.js application performance bottlenecks

Mike Sedzielewski — Mon, 15 Oct 2018 15:20:54 +0000

Here’s a case study from rspective site reliability team. This time we want to share a story of our customer. To reduce the costs of infrastructure (above 60 000 EUR per month) our customer decided to give up AWS in favour of baremetal + kubernetes solution. This transfer brought up the expected benefits (way fewer machines hosting databases and cache, way cheaper CDN cost) but for unknown reasons, it also highlighted the problem of increased resource consumption and growing latency on machines which host Node.js applications.

A threat of a partial return to expensive AWS hung over the business. So we decided to take a closer look at the problem from the inside.

We start profiling. The first step and immediately the first tough nut to crack surfaces on our way. An application, which locally generates call- and flamegraphs, doesn’t work in production. We switch to the manual v8 profiling which means starting the node process with the --prof flag.

Unfortunately, downloading and processing logs fails in the node version 8.10. Cause? A bug. The same thing in 8.12, fortunately 10.x allows us to move on.

We analyze the logs to check the CPU peaks and thus find out what takes up most of the processor time. We have a suspect - it's the “find” method of lodash. We optimize it and that helps. Converting the data format from a table to an object is one of the remedies that gain 20-30 ms on latency for several endpoints.

Clearly, we aren't satisfied yet. Profiling brings more suspects. One of them is a piece of code that impacts all of the request processed in the backend.

It turns out that another element from lodash - cloneDeep, which was supposed to provide immutability and was introduced over a year ago - with the current volume of data has a negative impact on latency and consumption of a processor.

This problem has been hard to capture because its influence on the overall performance has been growing gradually. As it usually happens during optimization, the long-sought trouble disappears after a simple change. In this case, it turns out to be replacing cloneDeep with Object.freeze.

We verify the patches for 1 kubernetes pod. The result - processor consumption decreases by 30%, the average latency for the whole supply is reduced from 140 ms to 30 ms. We decide for a rollout to all production machines.

The final effect looks satisfactory. At 700 pods with applied patches, average processor consumption decreased from 30 to 8% - which means we can reduce the number of pods.

By incrementally reducing batches of 100 pods, we reached 200 pod mark with CPU consumption of 44% peak time. Which is a better result than the initial peak time with 700 pods (~55%).

What have we achieved? We have freed up a lot of resources and gained space to handle more traffic and upcoming features. And, of course, the client does not have to go back to the expensive AWS.

ICYMI - we're hiring for rspective and Voucherify

DEV Community: Mike Sedzielewski

Becoming an e-commerce architect: 12 API integration skills for developers

Maximizing Customer Loyalty with CDP-Powered Incentives

Beyond the public codes — promo code types and their purpose

Iteration #1 — public promo codes

Iteration #2 — bulk codes

Beyond the homepage — funnel-aware promotions

Beyond the website — email, SMS, and push notifications

Beyond the manual promo codes — promotions UX

(Not) beyond the budget — fraud and margin protection

Beyond the POC phase — when push comes to shove

Beyond the promo codes — how about a full-blown loyalty program?

Amazon gift cards as referral program rewards with Incentives API & Voucherify

What you can build with Amazon Incentives API

API & portal access

The first API call

How to store gift cards

Testing & error handling

How to use Amazon Gift Cards in your referral program

Scaling and improvements

LTV developer

How to make martech POCs easier

The Challenges of Managing Promo Codes: A Syntax.fm Case Study

Decoding Commercetools Integration: A Peek Behind the Scenes

How to Fast-track a Referral Program with Voucherify, Segment, Braze, and Branch?

What were the rules of Pomelo’s referral program?

API-based building blocks of the referral campaign

Step 1 — Populate users across platforms (Segment)

Add Voucherify as Destination

Add Braze as Destination

Step 2 — Generate referral codes (Voucherify)

Step 3 — Assign referral codes to user profiles (Braze)

Bonus step — upload codes to user profiles in Braze

Step 4 — Create tiers for referrers (Voucherify)

Bonus step — Add more tiers (Voucherify)

Step 5 — Onboarding with deeplinks (Branch)

Step 6 — Manage your referral campaign

What's MACH and how it can make you 10x ecommerce developer

How we moved from MongoDB to Postgres without downtime and cut our costs by 30%

How to use the cloud to build applications faster

API-first building blocks instead of your clunky POC

Business apps is copy-and-paste-and-change-one-thing

Quick and not-so-dirty internal apps

The cloud is here, use it

Hunting down large-scale Node.js application performance bottlenecks