Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: If you're running a software as a service application or an enterprise application for web and mobile users, you will likely need to select services for analytics, customer communication and campaigns. There are lots of commercial options, open source options as well, but in the world of AWS, there is one service that tries to rule them all, and this is Amazon Pinpoint. Pinpoint promises to make it easy for developers to integrate these capabilities and also to meet the needs of the market.
However, we have just heard some surprising and a little bit worrying news that causes to question the future of Pinpoint. Today, we're going to talk about Pinpoint, its capabilities and the recent changes that makes us a little bit worried and makes us ask, is AWS going to kill Pinpoint? My name is Luciano and I'm joined by Eoin for another episode of AWS Bites podcast. fourTheorem is the company that makes AWS Bites possible. If you're looking for a partner to accompany you on your cloud journey, check them out at fourtheorem.com. So, Eoin, should we start by maybe giving an introduction on what Pinpoint is? I recognize it's not probably the most famous AWS service and maybe some people haven't heard about it.
Eoin: Let's try to describe it, what it is, what it does, and why it can be useful. Yeah, when it came out, and since I've heard a lot of people excited about it because of the range of things it can do, it hasn't seemed to live up to the hype in some ways of people talking about it, articles, blog posts, the kind of thing where you wonder, is it just used by a couple of large enterprise customers who just don't talk about it, or is it something that hasn't seen the uptake that we expected?
It's designed to solve a lot of different things in the marketing space. So if you imagine what you might want from a SaaS application is to track user engagement and key metrics, the first thing Pinpoint will tackle is basic analytics. If you imagine things like Google Analytics, Mixpanel, Hotjar, Fathom, analytics within Pinpoint is an alternative. As a developer, you would typically just use the Amplify SDK, integrate that into your client.
So that would be your web client, mobile applications. It can also integrate with like your Cognito user pool, or you can import your user data and your segments from somewhere else. And then you can immediately get automatic metrics, like you'll get metrics on sign in and engagement with the user interface, but you can also get metrics relating to specific things you're trying to track by adding in custom metrics in your client application with the Amplify SDK.
And that will send them directly to a Pinpoint API and stream those click events up or whatever those engagements are you're tracking. And then the next thing is kind of communication and engagement. If you want to send either transactional messages or promotional messages to specific categories of users, Pinpoint is also geared towards that. So examples of transactional messages would be sending one-time passwords or reminders to users.
And then you've got promotional messages designed to convert, upsell, reduce turn, maybe things like abandoned cart follow-ups. So you've got channels like email, SMS, phone, push notifications to mobile devices, and you can also add your own custom channels as well. So if you want to support some custom messaging service or WhatsApp integration, you can do custom integrations as well. The difference, I suppose, between this and using some of the lower level services like SES and SNS for engagement is that Pinpoint will give you tracking of engagement as well.
So it'll give you the number of opens on emails and messages and engagement with push notifications too. It's one of the few AWS services where developers wouldn't interact with it as much as your marketing team would. So you'll actually find your marketing team in the console engaging with it, looking at metrics and creating campaigns and stuff. Once you have your analytic and you've got your users on the system, you can create segments of users, and that can be based on a lot of different filter criteria.
Then you can create campaigns that will use the channels like email or SMS or whatever to reach out to those users. You'll create your campaign with a channel, you select an email template or a message, then you pick a schedule. And Pinpoint has that capability for you to say, okay, I want to send this out over the course of the weekdays, but I don't want to interrupt my users during a quiet period.
It'll even adjust that to the user's local time zone. So you can imagine if you were building all this stuff with SES yourself, there's actually quite a lot of complexity. If you think about other products in the market for messaging and engagement, you're looking at Twilio and MailChimp for this campaign stuff segment is a good example. You also have Salesforce marketing and Adobe marketing products that do similar things.
If you have an application that has a use case consisting of multiple steps, you can track a user's progress through that journey and then take actions to try and encourage them to fulfill the journey to its completion. Examples of user journeys are tracking signups to ensure that users log in and then actually use the application once they signed up or bringing new users through an onboarding process and also maximizing the number of sales and conversions, for example, following an initial free trial.
It's almost like step functions for marketers in some ways because you design the flow, but then you track the user's engagement and can see how successful it is at each point and as a whole. And you can also do sort of multivariate splits, random splits of users and everything, take different paths in that flow for different users. So there's a whole visual designer in a canvas there for that. Just finally, reporting is a big thing.
Pinpoint analytics doesn't allow you access to the raw data by default. You're essentially looking at aggregate data by demographics, et cetera. But you can also stream the events that you capture through to Kinesis or Kinesis Data Firehose. And then once you have it in there, you can take it into Redshift or S3 and then use things like Athena and QuickSight to visualize and report on it. Hopefully now that we understand kind of what it does and what problem it solves, we can kind of understand why it might be a bit of a concern. The messaging we've seen around recently, this kind of relates to quotas and limits. So Luciano, do you want to take us through the limits around Pinpoint and the bombshell? Let's start by discussing the limits first.
Luciano: So the bigger one to start with is that Pinpoint is not available in every region. For instance, it's not available in South America. So you'll need to go and choose one of the bigger regions. And there might be some compromises with that, especially if you are far away from those main regions. The other one is that you have a maximum of 90 days retention. And you can kind of work around that. You already mentioned that you can stream data to Kinesis using Firehose and send data to S3.
So you can basically use this process if you want to retain data for longer. But Pinpoint itself is going to hold the data for no longer than 90 days. The breaking news that we wanted to mention is that a week ago, AWS sent an email to customers using Pinpoint and basically changed a little bit the limits that the quota that you have in Pinpoint in a way that we think it's actually quite important and might have interesting side effect.
And there are different changes, but the most interesting one is that you could originally have 7,000 events per second per account. But from October 22nd of this year, the limit changes from 7,000 to just 15. So this is like 99.8% reduction of throughput. And also, AWS says that this is an hard quota, so it cannot be increased. So it's literally going from 7,000 to 15, which is like going from 100 to zero almost.
So it's, of course, obvious to start to ask very hard questions like what can you really do with 15 events per second? Is that going to be enough? Especially if before you had 7,000, was it like massively more than you needed before or now it's just too low? What's going on here? And we can speculate a little bit and try to figure out from the AWS perspective what is the motivation for this reduction.
We have a few ideas. The first one is that the more, I guess, negative one is that AWS is just using this strategy to try to kill Pinpoint. And they don't want to explicitly sunset it, but they want to reduce usage drastically to the point that nobody's using it and then maybe eventually they can get rid of it, which is very concerning because we are familiar with other cloud providers killing products all the time and not really caring about what happens to the users.
But to be fair, we always had a very good experience with AWS and there are very famous cases like SimpleDB that technically doesn't exist anymore. It's very hard to find material online. It's very hard to see anything in the AWS console. But we know that there are old users that still have access to that and they can still use it. And AWS is supporting that, which we always seen that as a commitment to keeping the user, giving them a good experience, making sure that the cloud provider actually removes concern from the teams.
And so in that way, it's kind of a partner more than a liability. So if that changes, I think AWS is kind of putting themselves in a little bit of a dangerous position from a marketing perspective, from a security perspective. And as consultants, we often hear this kind of concerns from customers and we can always reassure them by saying, look, we have been in this business for a while and we've never seen the same things that we have seen in other cloud providers.
So we are relying on AWS and we trust them. So if that changes, I think it's going to be an interesting conversation. The other point that is worth mentioning is that it's a product, as Eoin, you mentioned, that is not really focused for technical users, which is a little bit different from what AWS mostly does because AWS always provides API infrastructure as code and automation built in pretty much every service.
So every service is very geared towards developers. This particular service is more marketing focused. So I think there might be a little bit of attrition there in the way that AWS builds services, builds UIs to give marketers a very good experience. So just by the fact that users have to go into the AWS console, if they are not technical enough, if they don't know AWS, it might be a very distracting experience.
It might not be very well optimized for the kind of workflows that they need to do. So maybe that's something that AWS is recognizing and maybe wants to do something about that, maybe wants to create an alternative service, or maybe wants to start, wants to focus more on kind of the core functionality, like messaging like SES, SNS, and just rely on partners like Salesforce, Market, or Segment, Wilio to do kind of the user-facing part. Again, it's worth reminding that AWS has a very good reputation for not killing services. So maybe we are kind of exaggerating the problem, but it's worth asking these other questions. There is another option there. Like it's not necessarily AWS trying to kill the project. Maybe there is a pricing conversation to be had there. And if you look at the pricing of Pinpoint, from the outside, it actually looks quite cheap.
Eoin: You've got 100 million events for free in the free tier before you pay anything. So after that, it's a tiny fraction per event. So then it might start to count. But I guess for a lot of startup applications, they won't get even near 100, particularly while the user volume is small. Yeah, absolutely.
Luciano: So the idea that is maybe AWS is recognized that they are not being profitable with the service with the current pricing model. So maybe they are trying to reduce the usage. Maybe they will change the pricing a little bit, or maybe they will have private conversation with the heavy users and try to figure out how to make the product better for them, but at the same time, figure out a price in the works both ways. So these are just speculation again. We don't really have official news from AWS at this point. So you can, of course, come up with your own opinions, but I guess it's fair to ask what happens next. Like if you are a user of Pinpoint, what can you do now?
Eoin: If I was using Pinpoint at scale and really relying on it, it's definitely in a question to be had with your account manager at AWS and your solutions architect to figure out what is the strategy. I've looked in some of the accounts that we are working with, and I can still see that we've got the quota of 7,000 events per second. It's not clear whether the new limits will only apply to new accounts or to existing accounts or to existing Pinpoint users.
So there's definitely clarity required. And I think that's the main challenge here, actually. It's not just a limit decrease in its own right. It's kind of the limited communication around it and the clarity from AWS. It would be good to understand what the strategy is for Pinpoint, whether you should stick or twist. If you're planning on adopting Pinpoint, I know customers who are either using it or are planning on using it, and this is obviously something that's going to scare people quite a lot.
Pinpoint did have this advantage of having all this capability within AWS, so you didn't need to integrate lots of third-party solutions. And it would be nice to have that option of using it, but using it at scale, because 15 events per second, I mean, if you can imagine one user clicking around a website or a mobile application, it's easy enough to create hundreds of events in a few seconds for one user.
So if you've got thousands of users, you need to have that capability to have thousands of events per second, I believe, and to be able to increase that as your business grows. So there's lots of alternatives out there that people are going to immediately go to if they need something today, Google Analytics, Segment, Mixpanel, Adobe, all of those for email communication within AWS, you can always just use SES and SNS for the SMS and push notifications.
You'll just have to do a little bit more work to set it up. And if you want to track and analyze user events or just track events in your application, you could always do the kind of vanilla raw approach, which is to capture them and send them directly to Firehose or Kinesis from the applications, which will give you a similar kind of data set. Again, it's just not as seamless as it would have been with Pinpoint.
So let's hold out for some information. It's nearing the 22nd of October at the time of recording. So we'll kind of keep a keen eye on any communication around this and any other chatter. There's very little, there is one Reddit thread where this is being discussed by people using Pinpoint and there's a lot of concern there. Maybe we can link that in the show notes too, but there's very little chatter about it. I couldn't find anything on Twitter or any other social media outlet. So we'll kind of keep a close eye on it and let you know as well if we hear anything official.
Luciano: Yeah, I think that brings to the end of this episode, but before we wrap up, we'd be very curious to hear your opinion in general on Pinpoint. Have you been using it? What was your experience? Are you planning maybe to use it in the future and why compared to all the other alternatives? I'm curious to know if you have other speculations in why this is happening or what will be the future of this service. So definitely reach out to us and let us know if you're watching on YouTube, leave a comment, otherwise reach out on social. As always, if you find value in this episode, give us a shout, give us a thumbs up, reviews, share it and help us to grow the channel. We recently reached 2,000 subscribers on YouTube. So that kind of makes us very happy. So thank you everyone for following us so far and for supporting us. We'll see you in the next episode.