Innovation Series: What's Possible in Marketing Cloud?

Announcer: Welcome to the In The Clouds podcast. In The Clouds is a Marketing Cloud podcast powered by Lev, the most influential marketing- focused Salesforce consultancy in the world. Lev is customer experience- obsessed and podcast hosts Bobby Tichy and Cole Fisher have partnered with some of the world's most well- known brands to help them master meaningful one- on- one connection with their customers. In this podcast, they'll combine strategy and deep technical expertise to share best practices, how- tos and real- life use cases and solutions for the world's top brands using Salesforce products today.

Bobby Tichy: Welcome to the In The Clouds podcast.

Cole Fisher: Oh, no.

Bobby Tichy: I had to wake up a little bit.

Cole Fisher: I was like, is that real?

Bobby Tichy: Oh, it's real for sure. Welcome to the In The Clouds podcast. You've already heard our illustrious guest for today, Brett Phillips, but we'll give him a more formal introduction here in just a minute. Cole, thanks for joining. We're continuing our innovation series with one of Lev's lead solution architects, Brett Phillips, today.

Cole Fisher: Yeah. We spoke with Brett before and he's a wealth of knowledge on some pretty cool stuff, and actually runs a little bit of a segment here at Lev called... correct me if I'm wrong, Brett... but isn't it called Is It Possible In Marketing Cloud? Is that the name of it?

Brett Billups: Oh, yeah.

Cole Fisher: Brett is a wealth of knowledge on what can and can't be done, and Brett, I like the angle you take on a lot of these issues, is the answer is usually yes, but how does it need to be yes. I was going to say the same sort of thing, like your answer's probably yes at some point, it's just does it make sense to be yes. There's a lot of things we can do, it's just does it make sense. Today we'll go through a couple of some cool innovations that you've been a part of lately in Marketing Cloud.

Brett Billups: Perfect. Sounds awesome.

Bobby Tichy: If you wouldn't mind, Brett, just doing a brief introduction of yourself, obviously professionally but personally as well, and then we'll dive right into it.

Brett Billups: Yeah. Brett Billups. I am actually a senior manager over our solution architects here at Lev. I have a wife and two kids, and I've been around at Lev for about going on four years now.

Bobby Tichy: It's been four best years of your life, right?

Brett Billups: The four best years of my life, man, but it's a solid place.

Bobby Tichy: I'm so glad you said it's a solid place and not the opposite, like, " This place is the worst."

Cole Fisher: "It was good, but the last three years when Cole showed up have just been atrocious."

Brett Billups: Oh, that's when it got real sketchy, indeed.

Cole Fisher: Things really tanked at that point.

Bobby Tichy: Wait, who's Cole?

Cole Fisher: Brett, I want to dive into some of the cool things, and we'll outline a few here that you've been working on lately. I actually don't know firsthand about the solution, but I've heard rumblings about couponing for web and in- store capability that we've been working on. Can you tell us a little more about that?

Brett Billups: Yeah, for sure. Very recently had a client that actually wanted us to replicate the functionality of a couponing tool they were using. We needed to replicate that functionality within Marketing Cloud. There are some things you can do within Marketing Cloud that are pretty straightforward when it comes to assigning coupons and things of that nature, but this solution required a little bit more than that. Just to talk about the solution and why we needed to come up with it or what the requirements were around it is that in this particular case, we needed to solve for several different opportunities, several different issues. We needed to have a coupon that they could display, that somebody could pull up on their phone, scan in store, or print out and have scanned in store. We actually needed a version of the coupon that could be printed at the POS system or even accessed at the POS system, in case the customer was having issues. Whoever was at the POS system could easily bring the coupon up on the screen and scan it for a service for the customer, so we didn't have to keep going on and on there. Then we also had to build a page for the internal team to reference, for when they needed to test coupons. They had a lot of use cases for the in- store coupon piece of the solution, and then the other part of the solution was the web solution portion of it. I'll start with the in- store coupon part of the solution and what we came up with. Essentially the way we went about this was they needed the ability to essentially enter a campaign into Marketing Cloud, and just by entering that campaign into Marketing Cloud, they wanted to be able to produce a coupon. Because in there in the tool they were using, somebody from the marketing team would go in, type in a few things, hit Enter, and then a coupon would be available for them. We needed to replicate that, that kind of UI feel.

Bobby Tichy: Is that a separate system that's generating a unique barcode or something like that, or what's happening there when the crosstalk process happens?

Brett Billups: Yep. It's a system that generates a unique barcode for them to use. It essentially generates, in their old scenario, almost like a PDF or an image that had the coupon, and then they would go place that coupon in an email. There'd be an extra step for them that we were able to get rid of with Marketing Cloud, but yeah, it printed that all out for you.

Bobby Tichy: Gotcha.

Brett Billups: Yep. In Marketing Cloud, we've tried to set up a very similar setup. What we allowed them to do is to import the data that they wanted for campaigns. Then instead of them having to take that extra step and then take that data and go plug it in an email or something of that nature, through the use of landing pages/ cloud pages within Marketing Cloud, we were able to code a page to essentially look at that one source where they're dropping all their coupon data at, look at that one source and pull in the right email, based on whatever source we were giving it. Really the only step that they had to take within the UI is when they were creating their email. They would have to name the email the same name as whatever they named the coupon when they inserted it into that data extension or into a table. Once they named the email the same thing that they named the coupon, when they built the email, they would throw a special link in there that we built for them, a dynamic link, and they would put that dynamic link behind whatever button needed to be pressed for the coupon to be produced. I guess I said one step. That's two steps, right, so I lied a little bit. My bad.

Bobby Tichy: That's okay.

Brett Billups: Once they hit that button, essentially what happens is that cloud page goes and pulls in the name from the email. Then it uses that name from the email to look up on the table how many coupons are related to the name, and then it will pull in those coupons to the page. If they had three coupons that had the same email name associated with it, the page will display three coupons. If it had one, it'll display one. It took a couple of steps out of their process for them, and we were able to essentially replicate the functionality of their other tool with the combination of custom code, cloud pages and what are called data extensions or data tables within Marketing Cloud.

Bobby Tichy: Very cool. This sounds like something that probably saved a lot of time, or at least a time efficiency exercise for them. Do you have any insight what it looked like prior to being able to do this? Was it just a completely manual process of pulling in those barcodes, and then maybe populating data extensions with those barcodes to pull into emails? Or what did that look like?

Brett Billups: Yep. Before, to your point, they would pull in the barcode. The coupon also had some text and stuff around it, because it had like, " Savings, 50%," and some text and the barcode and all that good stuff in it. They would have to produce that, then they would have to take that after they produced it, and then they'd have to build their email and insert that into the email before being able to test it, send the email. Now as part of their building of the email, they just need to throw on the link, make sure they're naming it appropriately, and they don't have to put any extra elements or any extra images into the email for their coupon to be available. No longer do they have to do it. They don't have to do it for multiple emails. Since they have that naming convention ability for the name of the email, as long as the email name is represented inside of the data extension, they can use this for as many coupons as they want. It's really an evergreen, scalable solution. It's a little less manual, back- and- forth, copy- paste- click work for them when it was all said and done. Then in addition to that, some of those other processes that the coupon leverages as well, we created versions of the cloud pages for the other use cases. There's a version of the cloud page for the people at POS systems. There's a version of the cloud page internally, for them to be able to pull up and test coupons internally if they needed to, to make sure that they're scanning appropriately and giving the appropriate discounts. Instead of them having to then also create different flows for each of those users, once they've dropped that one set of data in that data extension, these several pages are looking at that data extension and pulling that data back from them, so they only have to enter the data once. They don't have to go send a bunch of stuff to everybody. Now they just give each of those teams that need access to the coupons, they give them each a link. They have their own special link, each team. When they go to it, they'll see the list of coupons available if they're not expired, and they have access to pull them up and print them, scan and test against them, whatever they need to do with them.

Cole Fisher: Very cool. It sounds like you saved a lot of time. You must've made some friends over there.

Bobby Tichy: Gosh, I love Marketing Cloud. I think what I love most about solutions like that, to your point, Brett, was being able to then leverage the initial use case of just being able to populate the right coupon or give the right subscriber or customer the right coupon, but then make it work for the internal teams as well, for the other use cases they had across POS and other elements there. That's really neat. The next one that we talked through is around dynamic link shortening. Why don't you give us a little insight into the use case there and what we did to solve it?

Brett Billups: The dynamic link shortening actually was bred a little bit from the coupon solution itself. The particular use case is inside of SMS messages, text messages out of Marketing Cloud, the client needed the ability to shorten a URL, which you can actually do within the UI. It's easy- peasy. There's literally a button. If you're going and setting up an outgoing text message inside of the UI of Marketing Cloud's MobileConnect tool, there's a button for you to click and you can shorten the link. It's all good. The problem is, if you have a dynamic link and you press that same Shorten button, all the dynamicy... dynamicy? We'll take that word, right... from your link...

Bobby Tichy: That's about right, yeah.

Brett Billups: Yeah. It sounds good, right? All that gets essentially knocked off. It'll only take the base URL, and it will ignore anything that you were trying to do that didn't make sense to it. What we had to do there is we had to go into our back pockets a little bit on this one, because there is no standardized method to do this from a dynamic perspective. There's really a twofold solution, where we knew internally that we could post out to places, right? Post out means within Marketing Cloud, within a message, leveraging AMPscript. You can essentially send an API or send a post or send a call somewhere. With AMPscript, we were able to send an HTTP post, and that post, we're able to send it to some sort of endpoint. The first part of this solution was, " Hey, we know we can send data to an endpoint. We have that ability in Marketing Cloud through AMPscript, but where do we send it to?" Then we had to do a little bit of research and understand who they were leveraging or who they were going to leverage for URL shortening. Because in order to do this, they have to... well, I'll take one caveat back. In order to do this, you technically need to have some link- shortening partner, whether it's Bitly or Branch. io or something like that. You need to have a partner, because you hit endpoints to those link- shortening sites by free trials. They have testing and trial endpoints and things of that nature, but if you're not actually under contract or have a contract with them or have an account with them, there's a limit to how many of those you can do. This client has millions of millions of users, so the limits that are associated with the free versions weren't going to be acceptable for the volumes they needed to work with. Anyway, once we were able to understand and leverage which partner they were using for link shortening, then we started to dig into that API for that link shortener. We had to find out, all right, so through their API, is it possible to shorten the link, and then how can we shorten that link? We were able to investigate and figure out through their API, they do accept particular payloads, and those payloads can have custom or dynamic attributes, and it'll shorten that entire thing. With the combination of AMPscript and then the combination of the link shortener's API, in the SMS message, we're actually pulling in all the data we need for our link from Marketing Cloud. We grab somebody's identifier, we go look up whatever data we need for their link to be dynamic. Let's say we needed their subscriber key so we can dynamically send them to the page that they're supposed to go to. We pull that data down and then we actually build the link. After we build the link, we actually build an API call and a payload within that same text message, and then we also authenticate, because you have to authenticate to the endpoint so you can actually get through it, username, password. We authenticate, and then after we do all that, we send it to the endpoint and the endpoint sends back the response. Within that email, we're building the link, we're building an API payload, we're sending it to an endpoint, and then the response of that endpoint is actually the shortened link. We have all that happening within that message behind the scenes. Then the end result, once the message is actually sent out, is that the user gets printed out on their screen a shortened URL, that's formatted for a text message so it's not taking up too many characters, but when they click it, it actually resolves through the URL shortener or the link- shortening site. It resolves through there with all the dynamic elements on it, so they can get to their custom page.

Bobby Tichy: Crosstalk 160 characters isn't enough to do something cool.

Brett Billups: Right. To your point, that's the benefit. AMPscript, with its proprietary coding language for Marketing Cloud, when you're leveraging AMPscript inside a text message, it actually doesn't take up any characters. There's a ton of code in there that isn't being resolved or printed in the message, so it's not taking up characters, but to your point, there's a lot going on in that message behind the scenes.

Bobby Tichy: That payload that you're building within that AMPscript, did you guys just build all of that AMPscript within the message and MobileConnect, or did you use a cloud page or something like that to actually process all of those different elements?

Brett Billups: We're currently building the payload in the SMS message itself.

Bobby Tichy: Oh, that's really cool.

Brett Billups: Yeah, and then we're just sending it to the shortener and then the shortener is actually doing all the work to make the code dynamic, and then they're sending it right back all at the same time.

Bobby Tichy: I could see so many different use cases for that too. I'm sure you guys get them as well, different SMS campaigns to sign up for, or when you go to a site and there's a pop- up modal for you get 10% off if you sign up for a campaign. I actually just did it this morning on a running shoe brand site. I got the text message back, but of course it's not personalized whatsoever. The additional elements or solutions that you could come up with to really personalize the experience based on shortening that link, but still keeping all the parameters and all of the personalized elements within it, is really neat.

Brett Billups: Indeed.

Cole Fisher: Yeah. That's what I mean. The answer is always yes, especially with Brett, the Is It Possible In Marketing Cloud concept. The answer is always yes. It's just how do you get there. There's eight different ways, but I think it's a really inventive solution to get there. Thinking in SMS too, that's not the only obstacle that we run up against. It's just like character limits and the inability to, out of the box, shorten links that have dynamic elements to them. We also have issues pulling contact key. I know that you've done some workarounds to that as well.

Brett Billups: Yeah, indeed. That's a beautiful tie- in, man.

Cole Fisher: Hey, that's what we do.

Brett Billups: Along the same vein, right, SMS. The reason, so to your point, when you send an opt- in message to somebody, just like, " Hey, we want you to opt in to our messages, ABC," you can either do a single opt- in or a double opt- in, whatever it is. When you send an initial opt- in message to a user, I guess I'll say believe it or not, but some people may believe it if you're not in the tool every day, but there's no easy way to pull somebody's contact key in that initial message. It's not available through any back- end tables. Well, I shouldn't say through any back- end tables. It's not available through any traditional, normally accessible tables or anything like that. It's not available in the UI. The contact key, for anybody that's wondering, it's just a unique identifier for Bobby or Cole or Brett inside of the Marketing Cloud platform, so I can know exactly who you are and I can know exactly who you are across omnichannel, whether that's SMS or that's Audience Studio or if it's email. I can know you're the same person through all those channels because you have something called a contact key. Anybody listening to this, if you're in the Marketing Cloud system using it, it's contact key. It's referred to as contact ID sometimes. It's also referred to as subscriber key, just so you have that breadth of knowledge with what the contact key is. Back to the solution here is with that contact key, we can't pull it into that opt- in message. That was a problem because for this particular solution, the way that a user would subscribe to text messages for the client was they would take some interaction on their website. Traditionally, sometimes what you'll see is we'll have a campaign, an opt- in campaign, where we maybe throw it into an email, or maybe there's a billboard outside of my shop or maybe there's a commercial on TV that says, " Text JOIN to 123 to join Brett's text messages," right, and people will actually text to join. Well, in this case for this particular client, that wasn't their method of having people opt in or join their text message flow. Actually the only way to do it currently is for them to interact with the client's website. When they interact with the client's website and they hit Go, there's an automatically- generated API call. It's called a QMO. That QMO call essentially initiates a double opt- in message to the user. We're not getting their phone number directly. It's coming through this QMO, it's coming through this... sorry... API that's coming from the client's website. It's triggering inside Marketing Cloud to say, " Hey, I'm giving you this number. I'm giving you this subscriber detail. Go send that person an opt- in message." The challenge with that is, within Marketing Cloud for this particular client, the contact key is equal to something called EID in their system, an enterprise ID in their system. The only problem is, for every person that touches their website and they activate that opt- in message for, they don't have an EID for every one of those people, so sometimes they have to send us something other than the EID, right? What we wanted to do or what our solution was is like, " Okay, if we can capture who you're sending us right when you shoot that initial text, we can write those people to a table," right? Leveraging AMPscript, when you send that message, we'll write that person. We'll write whatever key you sent us and we'll write their phone number to a table. We'll write what short code they came from. We'll just write a line of information for that record. Then that record can be used down the line to go and reconcile against our database. Because initially, like I said, for some of the users, they wouldn't have that EID or the enterprise ID. Instead, they would send us a different ID. It's something called a person ID, that's automatically generated on all their accounts. What we wanted to do is if I found anybody with a person ID, I would want to go reconcile them against our user database, because eventually at some point that person would get an EID. I'd want to reconcile them against the user database, go get their EID, and update their mobile contact list with the EID rather than that person ID they gave us. The reason for that, why you want to reconcile that ID and make sure we're always using that EID is because once again, if we go back to the concept of that contact key... and I'm using a lot of IDs and keys, so hopefully the trail is being followed here... but that contact key, in our case it's equal to EID. That's inside. It's that unique enterprise identifier for them.

Cole Fisher: Your person ID is the temporary holding for until they have an EID?

Brett Billups: You got it. That's correct, yes, sir. That EID is what we're really using to do our omnichannel marketing and tie a user to any channel they might go through. To your point, since that person ID is temporary, we won't be able to connect that person through the channels if we were to just continually use that temporary ID. That's why we have to go do that reconciling. Then the problem was presented with the contact key. I'm actually finally getting to the solution now. The problem was presented because we couldn't pull that contact key in from that initial opt- in message. We have no way to know. All we can get is the number, but we can't get the contact ID associated with the number. Some people who probably have used the system and things of that nature before may say, " Hey, why don't you just create a filtered list," because in a filtered list, you can get somebody's contact key, which is fair. You can, but the only problem is I have no way to get the exact contact key/ phone number combination, if that makes sense. If I was to make a filtered list to solve this problem, in a filtered list, if you go query a filtered list, leveraging SQL within Marketing Cloud, all you pull back is a contact key. You don't get any other information. If I was to take that contact key and go reference a communication table or something to try to pull back whatever phone number I may have associated with that contact key, I might get the wrong phone number. I need the phone number that they sent me through that opt- in message. That's why it's so important to capture it at the time that the opt- in happens. To solve for our problem since the filtered list wouldn't help us, and then through the actual opt- in message, the only thing I could get is the phone number and not the contact key as well, we had to then take a step back and figure out, " All right, what do we know and what ways are we able to capture a contact key," just in general, right? Just throwing darts at a board. What ways are you able to do that, and one of those is through the Marketing Cloud API. Then we had to understand, all right, with the Marketing Cloud API, with mobile contact in particular, if I send a mobile contact number to this mobile API, am I able to pull back records with that contact key on them? We tested that and we were able to, so what we ended up doing is essentially what happens is when that initial message comes through, that initial opt- in comes through, we do capture the phone number and then all the other associated details, so like phone number, short code, their locale, and even the keyword that they're messaging to. We capture all that, and then we take that phone number. We have an automation where that phone number is then run against a script. That script goes and calls Marketing Cloud's API, plugs in that phone number, and tells it to give us all the contact keys associated with that phone number, because multiple contact keys can have the same phone number.

Cole Fisher: I was just going to ask if there's a possibility that multiple numbers are going to be across multiple contexts.

Brett Billups: Yep, so that's possible. Then we have a step in there that particularly pulls back the person ID. We might get multiple records back from a phone number or multiple contact keys from a phone number. One of the things we actually had them do is... Cole, you mentioned it earlier, like, " Hey, that's a temp ID," right? We actually have them, just so it'll make it easier for us to find these down the line. They actually append temp_ to the person ID. Whenever they're sending an ID through that's not an EID, they append temp_ to the front of it. There is no question that that's a temp ID, and there's no question on how we find those. When we're doing that callback, we then can filter down and say, " All right, only write back any IDs that come back as temp to my end table," right? At the end of the day, what that cloud page is doing, it's going and making the call to Marketing Cloud's internal API, so it's the phone number. It's getting back all of our IDs, filtering it down to our temp IDs. We then drop those temp IDs into a table, and that table that we end up dropping them to, since we pulled all the other data with the phone number like the short code and locale and all that good stuff, that table that results from that landing page or cloud page, it then has the contact key that we just pulled from the API, the phone number, and then all that additional metadata we need later for when we're doing our reconciliation, to get the right record for that person down the road.

Cole Fisher: The answer is always yes. If there's a way to do it, Brett's going to find it.

Bobby Tichy: Yeah. I think that obviously everything that you went through, Brett, is really interesting and really helpful to the client. I think the one thing hidden in there too that maybe different leaders across customers and Marketing Cloud will appreciate is making sure that we're keeping the number of contacts aligned in an allotment. That way, if I'm subscribing to a text message, obviously from a marketing perspective, I love the fact that I have a single view of who I am, but also I'm not paying for that contact multiple times because they're a different contact, or different key for email versus SMS and et cetera.

Cole Fisher: Yeah. This will sound kind of geeky, but there's something kind of exhilarating to coming up with that solution. It sounds like you went through a number of steps of the process of like, hey, this technically could bring up multiple IDs, bringing up one phone number. A lot of the times when we do the really high- level, up- front solutioning and we're like, " Okay, well, now we have a phone number, that'll correspond to a single contact," we make assumptions that don't necessarily always ring true. It sounds like you guys went through a lot of steps to make sure that all of those assumptions were being tested and worked around, when there were things like a single number that could correspond to multiple contact records.

Brett Billups: Yeah. For sure, yeah. Ultimately when we're solutioning here, we're trying our very best to capture all those caveats. I mean, sometimes it's impossible to capture them all, but you try your very best to capture all the caveats. You're building that steadfast solution at the end of the day. There's not a lot of band- aids or processes that have to be added to it afterwards.

Cole Fisher: Very cool. Yeah, thanks for sharing that with us, Brett. Appreciate that.

Brett Billups: Yeah.

Bobby Tichy: Guys, I just realized we haven't been recording this whole time.

Brett Billups: Got to do it all again, man.

Bobby Tichy: I'm just kidding. Well, thanks again, Brett, for joining and sharing the different solutions with us. We really appreciate it. Jumping into completely unrelated, Brett, I'll let you go first, but what you're most excited to do post COVID.

Brett Billups: Post COVID, I don't know if this will be a popular opinion. I don't know how people feel about cruises nowadays, but Disney Cruises has been emailing us quite a bit, and I think they might've rung us in. I'm excited about cruising, here maybe once all of this...

Bobby Tichy: You like eating mayonnaise- and- onion sandwiches? Cruises?

Cole Fisher: Let us prove to email marketers that if you just keep blasting out the message crosstalk.

Bobby Tichy: Why does it feel like every year for the last 25 years, people will say email marketing is dead, and yet here's Brett just grinding right through that stereotype? Cole, how about you?

Cole Fisher: You know, there's a lot of things. I think too I'm partly swayed by the fact that it's getting warm. It's springtime, summer's coming around. I'm getting a little swayed by it. I can't wait for summer concerts or being at a ballgame. I mean, nobody likes being shoulder to shoulder at a ballgame, but I think after a year of not being shoulder to shoulder with anyone, it's going to be a welcome reversal for us. I'm looking forward to just getting out and enjoying weather, and being able to cough in public and not have people stare at you when you clear your throat.

Bobby Tichy: Cole is going to sit down in the bleachers at Wrigley Field and just put his arms around both people on either side of him. He doesn't know them, but he's going to put their arms around them.

Cole Fisher: Then Security is going to put their arms around me, so it'll work out.

Bobby Tichy: "Do you know these people?" " Oh, no. I'm just excited to see them." I think I'm most excited. I think concerts is probably one of the biggest ones. I'm not a big concertgoer, but admittedly... and I think I mentioned this on a previous podcast... I really want to go see the Jonas Brothers in concert. I would really love to do that.

Cole Fisher: Why are we friends? Sometimes I ask myself.

Bobby Tichy: Also travel, just being able to go really anywhere without any restrictions. We go on a lot of Airbnb trips and that sort of thing, which obviously Airbnb has been able to keep going, but just being able to cross state lines or go to different places that you haven't been able to go to, that you took for granted before COVID. I think just getting back to being able to travel little bit more.

Cole Fisher: Yeah. Very cool. Hopefully it's all sooner than later.

Bobby Tichy: Yeah, for sure. Well, Brett, thank you again. We really can't thank you enough, not only for walking us through the solutions, but being a big, big piece of Lev. We're glad you're here. We're glad you enjoy it here for sure. Thank you again. We really appreciate it.

Brett Billups: Yeah, no problem. Appreciate you folks.

Bobby Tichy: Thanks, everybody. See you next time.