 Amy June and welcome everyone as Amy June said, yes, this talk is about advanced Google analytics and other integrations with Google tag manager. My name is Jenny Leonard. I'm a freelance Drupal architect back in developer and consultant. And I have a little note of the year I hope you like your three letter acronyms because Google analytics and Google tag manager are just full of them. So welcome, and let's get started. So what are we talking about today? Well, the key concepts that we're going to talk about are tags, Google tag manager, Google analytics, Drupal, of course, and the data layer. Okay, so first, what is a tag? So a tag is a piece of code served by a website to collect data about visitor activity or provide other functionality. Usually it's JavaScript and or might be might involve tracking pixels and some examples include web analytics, like Google analytics, kiss metrics, mix panel, advertising or remarketing, like Google ads or Facebook's pixel. So maybe testing like Google optimize or optimizely GDPR cookie compliance banners could be implemented using tags or maybe chat bots or customer support overlays as another another thing you might use a tag for. So Google tag manager, which will abbreviate GTM service, and it provides organization and versioning of tags. It allows marketers self service options to implement and change the serving of tags on a website. And once it's implemented for a website, then marketers don't need developer support, for the most part, unless a tag requires some information that isn't already available to it. So Google tag manager is one tag to rule them all. It's its own tag, and our website needs to serve that tag to visitors so that Google tag manager can then serve all the rest of the tags. It only collects the data that you actually care about because you have to configure it to actually do something with the data. It facilitates performance. So it has an asynchronous implementation. So you don't have to worry about Google tag manager, or generally the tags that it then serves third party tags from causing performance issues for your site which is great. And it also allows the data that is collected to be rooted through Google tag manager in the cloud to multiple services. So that can help, you know, in case you have multiple services that need to collect the same information, maybe use multiple analytics services, for example, they don't necessarily each need to grab the data themselves, maybe possible to wrap that through GTM. The main disadvantage of Google tag manager, compared to directly integrating your website with Google analytics is it takes more work to implement. But it's really an upfront investment. And once you've done that, you reap the benefits. Okay, so Google analytics, you probably know what that is. Very popular free analytic service originally for measuring activity on websites back in 2014 universal analytics or you a was introduced. And that also were separately can support mobile apps as a source of data. And our universal analytics has three types of properties in Google analytics their web properties apps properties and apps and web properties. And universal analytics was the latest incarnation of Google analytics until Google analytics for GA for was announced and began roll out just two days ago. And it's as best as I can understand a rebranding and upgrade of universal analytics apps and web property. That said it doesn't require that there is a mobile app you can use it with just a website, no problem. It does require creating a new GA for property. If you just had a website before. There is a way to migrate or upgrade existing properties. And it's the default for new properties, as long as your account I think has had this rolled out to it yet. As of an hour ago my account still didn't have this rolled out to it so I can't create Google analytics for properties yet. I don't have those new features in my account. So, as you'll see at the bottom bottom bullet point here this is really out of scope for today because I don't know much about it. One note, I did read that the measurement protocol is not supported by Google analytics for. And you probably don't know about this because it's a pretty niche case but the measurement protocol facilitates you taking and sending measurements from a server, as opposed to from a user's browser, or wet or mobile app, and sending those directly into Google analytics. And there are, I think there are some replacement technologies available for GA for but I don't know anything about them. Okay, so back to Google analytics. So the, your existing and new universal analytics properties are still supported so you don't have to worry about that. Google analytics requires that one of the following tags be served by your website, either the universal analytics analytics.js tag, or the global site tag, or g tag. G tag is newer. It supports Google analytics, as well as other Google products tags. So here I wouldn't go out of your way to upgrade from the universal analytics tag. If the only Google tag that you're, you're using or have a need for is Google analytics. That said, if you're starting fresh, absolutely use the new g tag. There's just, there's seemingly no benefit from going out of your way to upgrade. So Google tag manager, which we'll talk more about their universal analytics integration serves the UA tag, the universal analytics tag, the new GA for integration for Google tag manager serves the g tag. So clearly Google's moving in the direction of using g tag, but you're not going to run into problems if you start using the UA tag now. Okay, another key concept, the data layer. So there's a W3C specification out there from years ago 2013, I think, the customer experience digital data layer or CEDD LA catchy. And this is the basis for different companies, data layer implementations put very simply, it's a virtual layer of a website that contains data. That's what a data layer is. And, or specifically, it's a JavaScript array or object that temporarily stores information that can be easily accessed by scripts such as GTM. So some examples of that information could include page content metadata, things like the page title page description author, visitor information. Is it a logged in user? What's their ID? What roles do they have things like that, or events happening on the page. So somebody clicks on a button or makes a purchase. Google's version of a data layer is an array of objects. And Google refers to those objects as a rather to be what's within that object as variables. So in the screenshot here, you can see an example of two variables. One is page category, and the value there is sign up, and one is visitor type with a value high value. This is taken from Google's developer documentation. It's not specific to Drupal in any way, just to give you a general example of the data layer and what it contains. Okay, so the data layer basically acts as a queue into which information is pushed. And so here's some examples in JavaScript, you go to data layer dot push, and you're pushing the color red into the data layer. Or you can push more than one thing at once. So you might push a color, a conversion value and an event in this example. Okay, so let's talk about Drupal. That's why we're all here, right? So there's a bunch of base modules that we could choose from for integrating with Google Analytics. There's the base just plainly named Google Analytics module. That's got about 79,000 Drupal eight or nine sites reporting its use very popular. There's the Google Analytics module previously called G analytics, much less popular only 5000. There's a bunch of sites using that. Then there's Google Tag Manager, all one word 28,000 sites reporting using that and then there's Google Tag Manager. Notice different machine names, be careful if you're choosing which one to install. That one's obviously much, much less popular, and that is a simpler implementation, probably nothing wrong with it. But the Google Tag machine name modules been around longer, and that's what we're going to use today. So the first two Google Analytics and Google Analytics, those integrate Drupal with Google Analytics directly, whereas the two Google Tag Manager ones integrate Google Analytics via Google Tag Manager. So there's one other key module we're going to use here. It's called data layer. And that's got about 5000 sites reporting use and we'll talk a little bit more about that later. Yeah, so we're covering Drupal eight and nine today. But the key modules we're using do work in Drupal seven and all the same principles apply. So if you're on a Drupal seven site, you could still take advantage of all this stuff. Okay, so a few Drupal modules that we're not going to cover. So there's commerce Google Tag Manager, and that integrates Drupal commerce with Google Analytics enhanced e-commerce functionality. There's a domain Google Tag Manager module that provides domain access integration. So you could have a different Google Tag Manager container per domain. And there's the context data layer module. And that provides conditions and reactions for the context module, which can be a very powerful way of pushing some things on to the data layer. And thus into Google Analytics. So before we get to our goal today, let's take a quick pause. Amy June, any questions you want to ask at this time? They answered themselves in chat. So we're good for now. Okay, thank you. We'll move on. So the answer is, our goal today we want to integrate Drupal and Google Analytics using Google Tag Manager. Okay, so the key steps to do that. We're going to create a Google Analytics account and properties. We need to create a Google Tag Manager account and a container, gpm parlance. We need to disable the Google Analytics module. We need to, if we're using that already, because that will conflict. And then we want to install and configure the Google Tag Manager module. And then we need to configure Google Tag Manager, all the servers up in the cloud to pass data from our site to Google Analytics. Okay, so we're at Bad Camp. I represent Nice Camp, or Drupal Camp NYC. And we're going to use Drupal Camp NYC 2020's website as our base study for today. Because that's where I most recently implemented Google Analytics via Google Tag Manager. So you can take a peek at 2020.drupalcamp.nyc if you want to take a look at the code and kind of what's going on on the front end. And this is a Drupal 8 site. There was no previous Google Analytics integration worth using. So we basically started fresh with this implementation for Google Analytics. The site's developed locally using Lando and it's hosted on Pantheon. And Pantheon, as you may know, has dev passed in live environments. That'll be relevant later. And shameless plug, join us November 12 to 14. There are three tickets for the last North American Drupal Camp until mid-2021. So head on over to Drupal Camp NYC. Okay, so create a Google Analytics account. I'm not going to walk through these steps visually, all these steps visually because it'll just take too long. There are too many clicks and it's pretty straightforward. But I'm going to give you the highlights and what you need to do. So in Google Analytics, the top level container is called an account. Usually you'll have one account for organization. Now a large organization might have one account for business unit or for a logical group of websites and apps, but maybe just for one individual website or app is very important or they need to categorize separately for some reason. And when you create that account, that first account, it also creates that account's first property. And the property is basically a website. However, a best practice, and it's one that is uncommonly used, I would say, in the Drupal community, is to have one property for your live environment. And another property for your non-live environment. And this is very important because you want to make sure that your live analytics data is as accurate as possible, especially if you're making business decisions based on it. There's not much point in implementing Google Analytics if you're not actually going to make business decisions based on it. And there's nothing stopping you from having one property per environment. I think the most important step is to have one for live and one or more for your other environments. And that also facilitates testing. When you deploy Google Tag Manager configuration, you can deploy it to one environment, test it there, make sure it's working before you risk messing up your live environment. So for Drupal Campaign NYC's website, we have three properties. We've got a live property, test, and then we've got a third property for the Pantheon Dev environment and for any local environments. So it would be my local environment. It would be the local environments of my other peer developers. Okay, so this is just creating a property. You know, web property is what's most commonly used. I mentioned the apps and web property earlier, that's kind of what GA4 is evolving from. There's nothing stopping you from creating an apps and web property even if you don't have an app. It might actually be preferable because I think it might make the transition to GA4 easier. Not really sure. But you can create a web property, no problem. And you know, it's not hard, right? You add in the name and a URL to that website specifically to that environment. So here you see I'm creating the live environment if I'm pointing to the live URL. Okay. Now a little more configuration we're going to do in Google Analytics. So we're going to set up some custom dimensions and what you need to set up here really depends on your needs. But here's just some base, you know, data that we might want to collect that is going to come from Drupal. And to make it very clear and make it easier to search for these in the GA interface, I've prefixed all of the names of these custom dimensions with Drupal. So you can see Drupal entity bundle, Drupal entity ID, that would be a node ID if the bundle is a type node, and so on. So those are going to be important for, you know, using your reporting potentially. You might want to see how blog posts perform, you know, relative to some other content on your website, normal pages or something like that. Let's see how many people start visiting on one convert in or into a paying customer, for example. Okay. One more piece of configuration we're going to do in Google Analytics, and this is actually for the views. So a view within Google Analytics. And we're setting up a filter used for the view. And we're setting it, we're going to call it include anonymous. The idea here is that we're going to have one view that has only our anonymous visitors. So in this way, we're going to essentially exclude any traffic that's coming from logged in users. So this will depend on your needs, right? If you only have content editors logging into your website, you might not be using Google Analytics to track their interactions, and you may want to not, you know, bother seeing their interactions if they pollute your data. So this is one approach, and you can see in the, there's a filter with a type include, and we're including based on the Drupal user, UID, which is what we defined as a custom dimension. And on the right hand side, you can see the drop down menu for that select, and you can see in green at the bottom, all of the custom dimensions that we added in the last step. So we select Drupal user by UID there. And then you would go ahead and create additional views. You could create one that doesn't have this filter, and then we have all your traffic. You could have one that has only your authenticated traffic. Maybe you want to track authenticated user behavior specifically. Again, depends on your business case. And so here you can see, you know, kind of in the Google Analytics interface. So here we're in the CampDev local property. You can see the very top left. And we've created a view named 01 anonymous visitors. And we've added a filter that we just set up called include anonymous. Okay, so that's basically all the Google Analytics setup that we're going to cover today. So there's a lot you can do in Google Analytics, but we're really talking about Drupal and our integration with Google Tag Manager. Okay, so now we need to create our Google Tag Manager account and container. And generally your Google Tag Manager account probably should map to the Google Analytics account. And similar to Google Analytics, when you create an account in Google Tag Manager, it also creates that account's first container. Containers instead of macros, rules and tags. And container can support multiple environments. That's different than in Google Analytics where a property really should be just for a single environment. And generally you'll have one container per website. Although it's possible that you could have multiple containers in the website, but it's a less common use case. Okay, so here we are creating that new account. So here in this case, we'll call the account Drupal NYC. That's our nonprofit and covers both the camp and our monthly meetups and other activities in the New York region. And so for our organization, as I mentioned, we have a single account and we can have multiple containers within that. And oops, I'll back up a second. So the container setup you can see is embedded here. And so I put in the live URL because that's the default URL we're going to use, right? And that's where the Drupal Camp website. Okay, so Google Tag Manager has a concept called environments. And by default, you start out with a live environment and a latest environment. The latest environment is where you publish all your changes in Google Tag Manager 2. And the latest is just kind of a way of pointing to the latest changes you've made in Google Tag Manager without you having to deploy it somewhere specifically. But we're missing some environments. So we're going to go ahead and create a dev environment here. And all I have to do is add the name of the environment in the top left corner, I call it dev. And you can put a destination URL, so I put our dev URL from Pantheon down there. And that's all you have to do here. And also did that for test. And other, you can see I added an arrow pointing to other there. So I chose in Google Tag Manager to set up three environments, three custom environments beyond a live environment. So we've got the dev environment, test environment, and then other basically consists of local development environments. But you'll see why it might be named something like rather than local in a little bit. Okay, so I'm going to go ahead and click on other here. And don't worry, you don't have to squint to read this. But it'll pop up this little window here. And this is where you need to pull out the GTM off and the GTM preview values for each environment. Okay, so we grab those. I guess I should say why. So the GTM preview value basically corresponds to each environment. And it's just a ENV dash and then a number. And so each environment is going to have a different number. And then the GTM off corresponds to that. And you don't really have to worry about the security of the GTM off in this use case. All you have to know is you need both of them. And we'll show, we'll see later when we set Google up where we put those in. Okay, so we have to make sure we've disabled a Google Analytics module if we had one already. So we'll pretend we've just done that. Great. And now it's time to install the Google Tag Manager module and the Data Layer module. So we use Composer here and then Thrush where you can use UI to enable it depending on your setup. And now we're going to configure that. Okay, so this is the Google Tag Manager modules configuration page in the Administrative Interface of Drupal. You start out with a default container. And we only need that one default container. And just like in Google Analytics, there's an ID for your Google Tag Manager container. And so we pull that out of the Google Tag Manager interface and paste it in here. And then importantly, because we're having, we have different environments and we're setting this up for environment. We have to go to the Advanced tab. So if you click on the Advanced tab on the left here. And then we get a few more options. And you have to check the box includes an environment. And that, and then you get the option to paste in the environment ID, which in this case is VNV-7. And the environment token. That's what we pulled out earlier. Okay, now we're flipping over to our settings.php. Hopefully you can read this, but basically what we're doing here is we're providing different configuration overrides, depending on which Pantheon environment we are in. So if we're in the Dev environment, then we're using one environment, one Google Tag Manager environment. And we have the ID in the token there, separate for tasks, separate for live, and then we have the default, which is other. So on Pantheon, if you have multi Dev environments, other would cover that face. And depending on how you use them, you might want to specifically call them out here and have separate Google Tag Manager environment set up for them. But it's probably not necessary. It really just depends on your needs. And so you can see for the other at the very bottom we've got VNV-7, and then that environment token trailing out there. And this is important because when we deploy this to our different environments, we want to make sure that we are pulling in the right Google Tag Manager environment. This is critical to ensuring that we're not kind of messing up our live environment with the non-live environments. Okay, so the data layer module is the other one we just installed. There's a ton of configuration here available, and I'm not going to walk through each one. It's very self-explanatory. But just to get a general sense, basically what this module does is it adds data to the data layer. We have a question from Benji asking if we could use config split too for this. Ah, config split. Yeah, so I'm a big fan of config split. And you probably could figure out a way to do it. Yeah, yes, you could use config split. I decided this was an easier approach, but there's nothing wrong with using config split if you can make it work. Yeah, so back to the configuration here. So, you know, it might be tempting to check all the boxes, but then the data layer module is doing a bunch of work. And if you're not going to take advantage of that data on the data layer, there's no point. You're just having to do more work and there could be some negative performance implications of that. So, you know, depending on what you're going to use in Google Analytics or other tags that tag manager is providing, you're going to want to just check the boxes that you care about here. So we'll go through a few more screens of settings. The path architecture is kind of interesting. You know, if it's node slash and then a node ID, you've got path component zero path component one. You might be able to do some interesting things with that in Google Analytics reporting. We're not using taxonomies on the site. Or at least we're not tracking Google Analytics so we haven't checked those boxes. Now, so here's where you can ensure that the roles of any users are tracked appropriately. And then the data layer output keys section. So this has to map basically these names need to be mapped from here to Google Tag Manager and then from Google Tag Manager to Google Analytics. So we'll see these in another few screens. Okay, so now we actually have to configure Google Tag Manager that's up in the cloud to pass the data that is on the data layer of our Drupal site to Google Analytics. Okay, so on the left hand side, you see the part of the main interface for Google Tag Manager and we click on the variables tab. And then at the top of the page there's going to be a configure button next to built in variables. So we click on that. This screen here. And so now you want to check some of these boxes. So these are the ones that I checked here. And of particular note, the environment name is going to be very relevant to our setup. And then some of these other ones are just general information that will be good to have in Google Analytics. And so now you see all the built in variables are here on that variables tab. So these are the ones I checked. Okay, user defined variables. So I don't have screens of adding each of these, but it's fairly self explanatory interface. And we'll dive into these a little more in a bit, but you can see that we've got a Drupal entity bundle entity ID title type, the revision ID Drupal user roles. We've got the Drupal user ID, the UID there, and we've got two different versions here. And we can get into that in a little bit. We've got the roles. We've got a lookup table that basically maps the environment, the Google Tag Manager environment that is active to the correct Google Analytics property. We've got the DA settings variable. That's very important and we'll go into that in a little bit. And then we've got some constants that we've set up that basically contain the Google Analytics property IDs for each of our Google Analytics properties. Okay. So, where are we here Google Analytics. You know, okay, okay, so sorry, this is the trigger. So we were just a trigger. So we set up a bunch of variables. And then another key part of Google Tag Manager is a trigger that determines under what conditions a tag is served on the website. And so Google Tag Manager natively supports Google Analytics. As I mentioned before, there's a universal analytics integration, which is what we're using here. And there's the new GA for integration, which I know very little about. So here we are in universal analytics. And we're saying that we are tracking page views. And we're going to use this variable, the GA settings variable, as our Google Analytics settings input. And then at the very bottom you see triggering. And you can say there's see there's one firing trigger called all pages. And you can guess that that triggers this Google Analytics integration on every page. And you might be familiar from the Google Analytics module of, you know, having ways of not having Google Analytics fire, for example, for admin users, administrative users are on certain pages. And you can set up, you know, something like that with Google Tag Manager. However, it is more flexible to have that set up in Google Tag Manager interface. It's easier to change there and tweak, rather than having to have a developer do something on the Drupal site. Okay, so now we see we've added the Google Analytics universal analytics tag here with that firing trigger that we had before. And we're good to go. So we've basically we've done all the setup that we need to do, skipped over a few details for time. But hopefully you got the idea. And this is basically the end of my prepared slides here. But I can share my screen and walk through the settings and configuration in any of Google Analytics, Google Tag Manager or Drupal now. So I'd encourage anybody with a question to type it in the chat. And Amy June will ask that for you. And while we're waiting for questions, I'm going to switch my screen sharing over, and I've got a few things to walk walk through if there are no questions. Okay, so just diving a little deeper here and Amy June, feel free to interrupt me with any questions that come up. So this is where you saw the screenshot of earlier where we're configuring our filter. And that we have that include dropdown here where we selected the dropper user UID. And just to kind of hit home, but this is only an option because we added it as a custom dimension. And yes, you can't forget to do that if you want to, you know, take advantage of things like that here. And I'll just also point out here, the different views that we set up here. There's some great blog posts out there that give some tips on, you know, why you want to have a whole bunch of different views potentially. I already talked about having the anonymous visitors view and authenticated users view. So you can, you know, see their activity independently. And then an all view if you want to see anonymous and authenticated activity together. And then you might want to separate user ID view. Google Analytics has this user ID view concept. And then it's a best practice also to have a raw data view where you don't have any filters, you don't have any strange things going on. And that's kind of a backup of all your data where you can always go to recover and find something later. I'm going to hop over to Google Tag Manager. And so you can see that we have that single account Drupal NYC. And then we have two containers, one for our camp website and one for our main nonprofit website. And so we're here in the camp website. And if you're not familiar with the Google Tag Manager interface, we're here in the workspace. This is where we configure, you know, Google Tag Manager. And the tag that we added, that was the Google, the Universal Analytics configuration. And the variables is where I want to dive in a little more here. So we talked about the built in variables and here are the user defined variables. Remember, we had these constants down here for the tracking IDs from Google Analytics. So for dev and local, you can see it's, you know, that UA value. And we've got a different one for each environment. And that lookup table that I mentioned, basically the way that works is you say the variable type is lookup table. The input variable is environment name. And that was one of the built in variables that we checked earlier. And then the lookup table, you say, well, if the environment name is dev, then use this variable to fetch the Google Analytics ID that we're going to use. And so this is the magic where we map our Google Tag Manager environment to our Google Analytics property. And see here for the dev environment and the other environment in Google Tag Manager, we're actually using the same Google Analytics property. And that's why that property is named dev and also local. If we go to Drupal entity bundle is just a representative example. So we've created a data layer variable. That means fetch the value for this variable from the data layer. And importantly, we have to give the variable name from the data layer. So entity bundle here exactly as written is what we had configured in the data layer module for Drupal. And that's how we we map the bundle of an entity or a node from an entity from Drupal to Google Tag Manager. And then it also shows that we have a reference to this variable in GA settings. So let's go into the GA settings variable. And you can see the GA settings variable requires that we provide the Google Analytics tracking ID. And so that's our lookup table variable that we just walked through. And you can set some special fields here. So I set the user ID field, which is used by the user ID views, and we pass in the Drupal user UID. And that's the version where we've stripped out the value zero if it's present, so that it is clear that actually there is no Drupal user there. So we have custom dimensions here. So each index maps in the same in Google Analytics, and you're you're mapping those custom dimension indexes from Google Analytics to those Google Tag Manager variables that we defined. So here's that reference to Drupal entity bundle that we just saw. There's some other options down here. We use Tito for ticket sales. And so we've got domain linking set up there so that hits from our website to Tito, and hits on the Tito website all get wrapped up into our Google Analytics property. Okay, let's see anything else interesting to show you here. Do we have any other questions Amy June. Oh, you're good so far. Okay, so just another example of a custom variable. So here's one Drupal user roles, comma separated. And this is how we get the Drupal user roles from Drupal. And we pass it to Google Analytics in a easy to read form. And so on the data layer, the Drupal user roles. The Drupal user roles Google Tag Manager variable is a data layer variable. And so this is the value that it picks up there. And it's actually an array on the data layer. And so we need to get that into a text form for Google Analytics to consume. So you can't pass an array to Google Analytics doesn't know how to deal with that. And so all we're doing is separating each value with a comma. So it's a tiny little bit of custom JavaScript that runs on the Google Tag Manager platform to convert the array of roles to comma separated list. Okay, I probably run out of things to show you in Google Tag Manager itself. I wonder, there's anything else on the website that might make sense. So we can we can walk through some more of the data layer module configuration options here. Yeah, so these are some of the options you have where you can. You can say that I actually don't want to expose user information for every role. So you could have a role that is, you know, opted into sharing or something like that and only users of that role actually have this information shared up to Google Tag Manager and Google Analytics. Bit of a contrived use case but that's that's something you could do here. And I guess I should mention that, you know, you're not restricted to what's available in the UI here the data layer module includes the the Google data layer helper library. So there's a JavaScript library that you can use to do some neat things I haven't played around with it too much, but it's very extensible. So you can have any kind of custom logic you want to put something on the data layer and then configure Google Tag Manager to take, you know, that data and do something with it past to Google Analytics or another third party service for example. All right, so I'm going to stop sharing my screen here. And I see Benji had a question here. What sort of business decisions does Drupal camp NYC made based on its Google Analytics data. Yes, this is a pointed and appropriate question. So none. Not yet. And my implementation on the Drupal camp website was really more of a learning exercise for me. We're not, we're not set up to have our Google Analytics really set up properly. You know, to make some useful business decisions. The, you know, the key data for us at the moment is financial and we get that data elsewhere. It would be interesting, I think, to hook up the enhanced e commerce integration. So that when an attendee purchases a ticket, for example, or makes a donation, because it's free tickets. You know that gets tracked and we can have some reporting in Google Analytics, but the reality is for a once a year event like ours, with a bunch of volunteers running it. We're not using Google Analytics for business decisions right. And so this is more an example for larger businesses and organizations that actually would be taking advantage of it. Yeah, thanks for the question veggie. Thanks everyone. If you have any more questions, you can find me on bad camp slack or Drupal slack or Drupal NYC slack. Hope to hear from you.