 Ia, so thanks coming along, we are Cameron, that's me, I'm a solutions architect based out of the UK, I've worked for Acquare for about four years now. Being a solutions architect means that I kind of bridged the commercial and technical side of what we do. So I talked to people who are interested in using Drupal and Acquare products and I convinced them that we can do what they need to do and remove any technical blockers. With me I've got Will Eisner, who's a senior director for products, so do you want to describe what you do Will? Yep, I'm a product manager for Acquare, so my job is to help build the Acquare Cloud platform and Acquare Cloud site factors. Sure, okay. So just to put into context what Acquare does, I wanted to kind of talk a little bit about our vision. So we're always tweaking this and working on new ways to think of ourselves, but it's useful to have kind of a north star to attach ourselves to. I think at the moment we're talking about making it possible for dreamers and doers to craft the digital world, which is a little fluffy, but I think we can all be kind of confident that we're all dreamers to some extent or another. We all kind of believe in the possibilities, but the doing of it is what takes up all the time, right? So we want to try and take as much of the boring stuff out of the doing and make the dreaming a little bit more easy. And to do that, we want to deliver a universal platform for that. And a universal platform means in context like a subscription element where we provide a bunch of services that you can rely on. We don't lock you into anything data or we don't lock up your data. We don't lock up your code. It's all in support of open source. We really believe that in that as a company. And we want to create a product platform that makes it a lot easier, a lot more reliable. But a platform kind of means different things to different people. And a digital project means different things to different people. And all of these people have a stake in that and they have a lot of work to do. And they rely on a lot of tools and technologies to do it. So, you know, it's tempting at a Drupal con to think of it as just a developer. And that's my background. So that's often how I think of things. But obviously the business owner wants it to do what they need to do. The digital platform owner has a whole different set of responsibilities. And often the things that these people need to do can actually be in conflict. And what we've seen over, you know, lots and lots and lots of site builds for lots and lots of customers is that we see the same things happening. We see an opportunity to kind of ease some of the friction in that cycle. We will create a product that helps to do that. And that's what is responsible for bringing it to market. These are the personas that we use when we think about the products that we have. And so I'll kind of refer to these as we go through. Obviously they're personas. In a real world, there's a lot more people than just four in a team. If you think of Drupal, you could argue that there's thousands and thousands of people that are contributing to a site build. So we want to plug in where it makes sense to those people. And obviously we're indebted to the community for a lot of what they provide to us, but we try to give back as much as we can. So some of the stuff I'll talk about as well is open source, it's stuff that we contribute back into the community. So this is how we see a digital life cycle this year. It's always evolving. It's an iterative process. It's something that kind of never ends. You'll have an idea. You'll need to create some content around that idea. You'll curate that, put it out into the market. You need to orchestrate how that data gets in front of people. You need to analyse what's working and what's not working. Hopefully you can build up a profile of who's visiting your site and then enrich their experience. And so, you know, we've got products that sit against those. So what I'm going to talk about today, some of these logos might be a bit mysterious without text below them, but broadly, we've got Aquacloud, Drupalight and Lightning, Content Hub, Lyft and some other bits and pieces that fit into that. So there's a lot there, and necessarily we'll be kind of whipping through. This is the Trinity College Library, if you haven't been there, it's really amazing. But yeah, we're going to try and get through quite a lot of our products and because of that, we won't be able to go into a huge amount of detail. But if there's anything that you are particularly interested in, you can swing by the booth or find one of us or anyone wearing an equestria and we can either help you out there and then or we can put you in touch with someone who can go into more detail. So this is how we kind of categorise our platform and what it means in terms of practical tools that you can use. So along the top there you can see the kind of channels that end up being part of a digital programme. These are always changing and adapting. You know, something that's come out reasonably recently as having a lot of momentum is voice control. So it was on Echo, Surrey and lots of other things like that. But there's all sorts of things, traditional web of course, phone, chat, mobile, and on and on it goes. I guess the common thread that brings all those together is having an open and robust API. So everything we do, we're trying to push around via API and we hope to be soon totally API first on everything we do. The areas, so kind of at the base of that is cloud. So we've gone into more detail on that too. But you know, people want that to be secure, performant, elastic, so if you have a big spike, your site can grow to cope with that. But there's also a lot of management that goes with that and there's management from a technical level but also, you know, commercial. We spoke about those personas before the digital platform owner. How do you handle managing thousands and thousands of sites or hundreds or tens? It gets really complicated really quickly. So we're trying to provide some tools there. Experience assembly is kind of a fancy way to say CMS. Drupal and Lightning and some tools that plug into that and we'll talk about that. The bits on the top are kind of the services that can sit on top of Drupal and provide a little bit more value. So universal content is about getting your content to the right device at the right time and from any source. So any source, any destination can text your interactions about making sure that when I visit a site, it's right for me. When we'll visit a site, it's right for him and so on and so on. And that's challenging to do at scale. I think Drupal's historically been really good at that but doing it for every single visitor to your site and making sure that things work is a real challenge that we're facing every day. And that's where those products fit in. So I'm going to start talking about them one by one now. So I guess where we start is Equial Lightning. So Equial Lightning came out of a project that actually my team ran where we would give demos to clients who are interested in Drupal for a long time and we realised that we were just doing the same work over and over and over again. So we thought, hey, why don't we create a distribution or a package version of Drupal that has a lot of those features in one place. So instead of starting from scratch, we start with a kind of head start. And that works well and it still works well but then what we begin to realise is that there's a way that we could do that not just for demos but also for actual sites that are being deployed. Something we actually tended to hear a little bit was, oh, we saw this cool stuff in the demo but it didn't end up in our live site and we thought, hey, that doesn't sound right. So we took a lot of what we did in demos and we packaged it up. We used the release of Drupal 8 as a great opportunity to sort of reset how we do that and start from a greenfield to build a whole bunch of features into Lightning. So if you were to go to lightning.aquare.com or drupper.org and grab Lightning, you would get a package version of Drupal 8 that was already set up and configured for all these kinds of things. Layout, workflow preview, media, security integrations and testing and lots of other things besides. It's totally open source, developed in the open. And one of the nice things if you've been working in Drupal for a while and used distributions, you may have had the experience where the distribution will move on and be upgraded a version and getting from the version that you've got to the next version can be really challenging. We've committed with Lightning to maintain security and functionality updates that will be compatible and have an upgrade path. So if you start a site build on Lightning today on Drupal 8.1 and then a few months down the line Drupal 8.2 has got a whole lot of new stuff. There will be a way to do that with Lightning which will all be managed by us and supported by us and will be open source. Excuse me. So if you've been around Drupal for a while you'll probably be familiar with this what we're going to see. Where you would start, you'd do a site, you base it on Drupal, everything's fine, it works, you install a few modules, do some configurations, run some themes. Looks okay. But then you have to do two or three or five or ten more sites. So you think, hey, I'm going to create my own distribution, my own version of Drupal that does all the things that we need it to do and I'm going to maintain that. But clearly there's some effort in building that in the first place and then there's some effort in maintaining it that's additional to what you have to do to manage the actual sites that are there. So what we figure is that in a lot of cases you'll be able to take Lightning and remove a lot of that headache. So you can still have this, all the stuff that's in Drupal Core, you can still manage your sites on an individual basis but you can use Lightning to provide a lot of that base functionality that you would otherwise have to assemble yourself. And Drupal being Drupal you can put your own customisations on the top. Drupal, if you're new to it, has been developed in the open for like 16 years now and it's good at being modular. It's good at using code from different places. So Lightning's very aware of that and designed with the notion in mind that people are going to want to make changes and add plugins so that you can continue to use Lightning and have all the updates but also have your custom stuff and your sites and they can all co-exist. That's Lightning. And that's fine. It's all very conceptual but actually getting it from running on your laptop to running it live is a whole other story. Especially when you're running lots and lots and lots of sites. That becomes much more of a challenge and we see customers again and again that will have not only lots of sites but they'll have lots of teams. They might have different agencies and different locations. They've got different people they want to give certain levels of access to the code and some they don't and so on. We saw the need and we came up with this thing called the build and launch tool. We'll BLT for short. So that's an equity built tool. It's all there for creating new projects from a template with a lot of much the same way that Lightning's constructed with some out-of-the-box ideas and best practices that are baked into the structure. So that might not mean a lot when you see it there but when you think about all the things that you kind of need to configure and get right to get a project going that's big and complex and might need different things for different sites and different teams, there's a lot to configure. So the idea is that you create a project, you define what your base version of Drupal is, you define your tests your documentation you know your configs, how the code structured, what happens on site A or site B when it's deployed what happens in dev, what happens in prod what happens when you commit to git and so on and so on. All of that stuff has kind of been worked out and structured in a way that with a few of the scripts and tools that we provide you'll be able to set that up and kind of reduce the maintenance headache of maintaining that. This is something that you know a development manager or a build engineer could spend their whole week, month, year doing, we're trying to kind of take some of that off the plate. Again this is a tools project you've just got to git hub and fiddle around with it it's all quite well documented and it's an ongoing basis on an ongoing basis. So this is an example of someone setting up a new project based on Bolt or BLT, so you just define a few configs you know, he will send it some names some install profiles in this case lightning some upstream version control set which versions of modules or distributions you want to use database connections once that's all set up you can just run a script and it will start to build an archive for or an attribute for development and testing. So if you're you know if you're a developer in a use using composer or site install scripts this will be not unfamiliar to you. I'm trying to do it in a way that incorporates not only Drupal best practices but also around testing and documentation and so on. So I think you should run an install and you'll see I'm logging in. So this is kind of the use case of someone doing it on their local machine for development and that's typically if you're new to Drupal that's how a development works. People will have a version running on their local machine and then they'll deploy into an integration environment to do systems integration testing or QA or whatever and that's it. So that might not be that revelatory to you if you've kind of done this sort of thing before but I think what we're basically seeing is that we've kind of formalised a lot of the knowledge that we were seeing again and again on our own projects and we think it's made a difference, right? So we've got a big professional services team they're 100% years on every single project. It's like four weeks of developer time saved per project means that all of our projects have testing which wasn't necessarily the case before. It means that any custom code brought into the distribution or the deployment is compliant with Drupal coding standards which implies that it's probably more secure, it's easy to read or be easy to upgrade in the future and so on. And we also bake in some best practice around you can't deploy a module that's got known security problems and so on. There's a whole lot of other stuff going on but I think the kind of takeaway is that once you get your head around it it does tend to save a lot of time especially for those repetitive tasks that need set up on every project. We've got a bunch of internal testimonials from people saying that they don't get failures in deployment which is a nightmare it can be. Much less of a benefit like I probably think the overhead of doing it might not be worth it. It's also not the if you've already got an existing project it doesn't make a huge amount of sense to retrofit it into this but it's well worth looking into. It does have a few things set up like if you're planning to use Fing or PHP, a lot of that stuff is kind of already there so yeah. I mean we do use it on every project so that includes projects that are a single site but I think it's less useful but less useful with just one. Yeah. So you saw all that stuff that developer was typing into his console there and you know what we're seeing emerging a lot is that especially in Drupal Outland projects are built from a set of definitions they're built with composer they're not as simple as they used to be they incorporate a lot of tools and a lot of those tools make a massive amount of sense of development but they don't make so much sense when you push out to production this is much more so in Drupal Outland than it ever was in Drupal 7 and so there's a really good blog post actually by Michelle Cresci about deployment production is actually just an artifact of development your development can be thought of as like a factory and then your production is like the finished product and so we don't want everything that's in the factory out on the street you know it doesn't make any sense and a typical not even a complex project will use all of these kinds of things so there'll be some CSS preprocesses and frameworks there'll be task runners with grunt there's probably a GitHub or Bitbucket or something like that that's managing pull requests that needs code checking with code module there's BHAT tests, there's PHP units there's composer and so on we just want our site to be deployed out to our hosting which is hopefully Hacker Cloud and there's a lot of tools in there right so I won't go through these in detail but in a typical sprint cycle you know there's people using SAS there's people using composer there's people using BHAT and so on stuff I covered kind of before but this will happen at every deploy it might happen multiple times on a sprint getting all of those tools set up that do all of that stuff and it's a task in itself it's something to maintain so our idea is that we will have a managed service called Acquired Pipelines that'll run in the cloud you define a YAML file in your repository you deploy it up we'll see it there if it's there we'll say okay we're going to run some build tasks we'll spin up a temporary environment that'll do all of that for you so it'll run Node.js to run all the JavaScript tasks once it's passed all of the tests and all the codes in the right space we'll push it out to our dev-stage or production environment whatever you have configured so that means that you don't deploy code that doesn't work or don't deploy code that's not up to standard that's the idea we're going to run it as a service so we will maintain it in a way that makes sense for Drupal in much the same way we have cloud it's a Drupal runtime it's not a generic hosting environment it's tuned just for running Drupal projects it's actually in private beta at the moment it'll be in public beta next quarter or this quarter I guess now generally available generally available early next year so if you're interested in it come and find us and we can talk to you about getting you into that okay so we're moving up the stack now heading into cloud site factory so for those who don't know I don't think I've spoken to some of you before you may know that we run what I like to call a Drupal application runtime that sits on top of Amazon web services so it's a highly tuned highly available platform as a service that's designed just for running Drupal the idea is that you have your code and your content you bring us there and we handle all of the infrastructure issues around security performance, availability so on site factory extends that into moving from providing tools for hosting and managing your code into actually managing sites as a sort of logical unit so that you can run many sites across however many teams, locations however you organise yourself and you can have a dashboard that shows those you can govern them from a central place so you get a lot of the benefits that Drupal brings with multi-site but you get a software as a service tool that gives you clover heads up and what's actually going on at a site level. Cloud will save you a lot of effort because instead of having to maintain all of these things via managed hosting or via yourself we will handle it for you so we've got a dedicated operations team a dedicated cloud engineering team that's globally distributed who are monitoring AcquaCloud 24-7 we're actually running about 14,000 instances in AWS or more and we've got really good historical uptime it's highly available we have a lot of security certifications PCI DSS ISO 27001, FedRAMP if you know or you have to deal with that stuff you'll know a lot of those acronyms, they're a real pain to maintain but we handle it and it's really key to our business that we do so you can be guaranteed that if you deploy your code here you'll meet all of those standards which may be applicable to you or your clients requirements so I think one of the things that we'll show you today is kind of in line with what we've been talking about so far is the development tools that allow you to actually get your site out onto that platform so all customers get as a minimum development is staging in a production environment we really try to simplify the act of deployment if you're a developer you'll know that deployment can be really painful and if it's not reliable it can really introduce a lot of nasty bugs and issues and stress we also enable all of that stuff so you can do it in a web UI which is all permission managed and all that sort of stuff but you can also do it via an API so if you've got Jenkins or some other build system you can hook into it and run these kind of tasks remotely so you don't actually have to log in and click things this is an example of a typical use case where you might have finished a sprint and you're doing some sprint testing you want to grab the latest copy of the code so we're going to deploy the master branch to our staging environment give it a nice little message so that when someone checks the tag later on they'll know what was going on and then we're also going to pull down the code and the database from production so that we know we've got the latest configuration and content for testing so as you can see it's just a case of dragging and dropping between environments and then all of those site components will be pulled in, they'll be isolated duplicated and then you can do your testing so as I say all of this stuff is totally API-able so if you do have your own tools and systems anything that you see here can be done via an API that show around real-time log streaming around automatic backups around doing stuff via drash or the shell but that's kind of at the core of the development tools so in that example I was running in the cloud so you have a dedicated dev stage and production environment it's sort of typical day-to-day workflow would be you'd do your own code on your own machine, whatever you like whatever you prefer and then you start to integrate with the other people's code on the development or staging environments so you have an all-in-one product called Acquia Dev Desktop which is like a man-for-a-wamp environment which you can log into your Acquia account and it will pull down all of the sites that you have so that you can work on them locally and that's a really good way to get started quickly especially if you're newer to that a lot of people are quite opinionated like myself about their local environment so you don't have to do it that way if you want to do it your own way it's fine but we do have tools that we support regardless of whether you're an Acquia customer or not and they're really well integrated so yeah, the short answer is yes we give you something local so Site Factory is built on top of cloud but it changes the notion from managing code to managing sites so before we were strictly dealing with databases and files and vision control what this means is that instead of that you're managing at a site level so if you're familiar with Drupal I know about the concept of multi-site where you have a single co-base that can run one to many sites and I kind of alluded to that earlier we can also via this interface run across multiple co-bases or multiple geographies so to sort of show you what that means in practice this is kind of a dashboard where you could see a whole lot of sites that are deployed in live for each of the sites I can log in I have a centralized login mechanism I can do things like back them up or clear caches things like that I can filter on how busy they are what their domain is a whole bunch of other things and I can arrange sites into groups you can see there's a whole lot of groups along the left and you can control access to those groups on a very fine-grained level so as an admin I see everything but you might not want that have to have for this interface this is site factory that we're looking at the underlying kind of guts that makes Drupal run many sites is native to Drupal but to have this, this is a site factory capability so you can see there I've just created a new site and so it's as simple as that so I can go in as an administrator I can click a few buttons choose the distribution I want to use the location or the hosting cluster that I want to use give it a name, give it a domain click go and then the site will be built you can see there in my little group we've got our new site the site's been built eagle eyed minus seen that I chose the minimal and still profile which is kind of the minimum that Drupal will allow you to do and there's my site you can see also that my account on the site factory has actually been federated out to the destination site so I don't need to maintain a login for every single site in my network I'm an administrator I'll automatically get created as an administrator and I can just have single sign on across the whole group so we have a central Git repository and so basically we're talking so each site will have the way that the code is structured so that certain parts of the code will be applicable to certain sites but underline that as a single repository with stacks, is this a single repo or is it multiple repos? So we have this optional functionality which we call stacks which is where you might want to have multiple repositories because you've got sites that do very different things and then you will get one per stack so it's not per site, it's per stack but we can talk about that in lots of detail if you find me afterward What kind of clients are using Site Factory today? We've got a lot of clients so the one that we talk about a lot is Pfizer Violio Warner Music Group some other good ones that we can talk about So we go to CMS in Australia Yeah Finance Are they deploying blogs or even websites or only static content websites? I think it probably skews a little bit more towards marketing sites that are a little bit more static obviously they've got editors and they're CMS driven they're not literally static sites but I think in general it tends to where people have a lot of more simple sites There's no limitation there it's full install of Drupal every site is completely a full install of Drupal, you can do whatever you like but I think just in practice the mental overhead of managing a lot of complex sites usually means that they get broken out into their own environment I think yeah a great example actually of consumer package goods is a really good one because those companies will have like 20 brands say and those 20 brands might be deployed into 20 countries so it might be 400 sites per brand or it might be 400 sites total sorry how do you manage that how do you handle that when you want to keep consistency and not have to pay for a site 400 times over so we've got Nestle does that which is one of the biggest brewers in the world and it's a really good use case when you need to deploy into lots of regions and lots of languages so moving up again so assuming that you've got all your sites now deployed and running and you need to start moving content around between them so that stuff doesn't get siloed away so we talk about this generally as the idea of universal content and content becomes a service so Drupal itself is really good at structured content and metadata and within a single Drupal install you can do lots of really cool things and in fact you can share content out using APIs in lots of different ways but this is another case of us seeing people doing this in lots of different ways and thinking maybe we can standardise this and make it a bit easier for everyone so content hub it's cloud based content distribution and discovery service that means effectively it's a big database sitting in AWS with a whole lot of APIs against it automatic discovery and distribution of content we see this a lot we hear it a lot people have content all across their organisations sorry, skipped a hint and it's locked away so there's a whole lot of content that the team in Germany made which could be fantastic I don't even know it exists the UK team is creating a lot of stuff that everyone needs and the way they get it around is they stick it in an Excel file and email it it's just crazy again and again and again what that means is that instead of trying to actually reuse the content that's been created that expends an effort people just recreate it again and again and again it's just easier to do it that way than to actually use the stuff that's already there and it also means that content gets locked so that people won't even see it via the CMS where it might make a lot of sense to see it somewhere else on a different channel in a different place and we've created this cloud-based service and we've built a lot of connectors as standard that interact with the API and that can aggregate content from those providers and put it into a normalised database which then other clients can consume so magento, webpress, hybrus dobe, AEM, Drupal and lots of things besides it's a simple API it's easy to integrate with but we are continually building connectors as customers ask for them and making them available so in my cases we have customers who want to centralise content creation they want a single master site that pushes content out to all of their client sites or this is more complex but it happens a lot as well where every site is both a content producer and a content consumer and the content hub manages all of that stuff so that all of the other sites know about it so it unlocks the content silos that you can start moving content around it can either be hub and spoke or it can be peer to peer it doesn't need Drupal doesn't need to be the arbiter of who that sees what you could have systems talking via content hub that have nothing to do with Drupal of course we've got support for 8 and 7 and other stuff as well and they're ready to go excuse me so this is actually this is actually someone filling around with content hub in a Drupal 7 instance you can see this is quite simple content this is shown on a reverse chronological order but as soon as content gets put into the hub it's basically instantly available so this person is filtering through to see what's available basic filters around date, source stuff can be tagged and this is kind of using it in a manual fashion but it's got full rule support in Drupal so you can import content automatically and then put it into your workflow system so for example you might say if the site in the UK has new content automatically import it into my site but don't publish it send a notification to the content admin for checking so that they can review it before they actually publish it so that's content hub so the question was about how we deal with translations and that's do you want to cover that one? one method so we'd probably class it in a different category of tool so machine translation which is not something we provide but there's lots of tools that plug into Drupal that can do that there's free ones and expensive ones and everything in between I think in practice we've got lots of clients who run a multilingual suite of sites in practice they prefer to just get their people to do it because machine translation is great but it's not as good as a human either and it's complex content across languages is really complex and I think while there are some really good solutions out there people kind of throw out their hands and say I'll just let the guy in the corner do it but it's an interesting space so that from our perspective would really be Drupal's responsibility and it's really about your information architecture so today I think responsive web designers most sites start with that in mind and the idea that you can send for example a high-res image to a desktop and a low-res image to a mobile is really key there's a lot of JavaScript for example but that's handled kind of at the Drupal level so your information architecture might say give me a low-res image and a high-res image and you'll be doing that at a Drupal level but content hub will then push that image around the hub that's required there's a question about structure context images, different fields, that sort of stuff would be good for example for example content hub content hub so right now content hub is pretty flexible in terms of and so for the most part we do have people who are bringing content for others to invest in right now it's done we try to establish this content hub as an extension of the organization with place, editing in different sites edit there and then push out so content hub is just an API-driven service for the interface of its own well I think every single implementation we've done Drupal becomes the editing interface and the management interface but that's not strictly necessary but yeah we don't see content hub becoming kind of a web app where you log in and edit content that's not what it does, it's kind of plumbing to join sites together so it will be imported completely structured content so you'll just have that interface I showed before, you'll be able to say import this and typically I think if you're doing Drupal to Drupal communication it will be the same content type so news article is another news article but again that's not strictly necessary you can create some rules on your side that says if I get a news article from site X, Y and Z convert it in this way so the ideal is that a lot of that stuff just happens automatically so as soon as a site is published out or a content site published on a given site is pushed across other sites in practice I think most people want to make sure it's right before it goes out but it stores references to images right now so it will store a URL to an image and then on the client site will ingest the image is that right? yeah so the short answer is yes cool so the last product I guess I'll talk about is the left and this kind of sits right at the top so if you think of BLT and Lightning and Cloud as kind of representing the code and Site Factory as representing the site this kind of represents the visitor, the person and so the idea is broadly it fits into the personalisation category and the idea is that we can know about every single visitor that comes to the site and deliver them customised personalised experience depending on their device or the channel or the context in which they're visiting and you know Drupal's actually been quite good at what we call explicit personalisation for years and years which is when I've got a user account on a site and I say I like this and that and this other thing Drupal's really good at editing a page or adaptively changing a page to suit those preferences what it's maybe not quite as good at is doing that for anonymous users that it knows nothing about there's some challenges there because clearly we don't know anything about them when they turn up that's the biggest challenge but there's also some performance issues some management issues how do we handle that so we have created this idea of Lyft which is a client that runs on top of your Drupal site allows you to track a range of behaviour about the user so broadly that's situational behaviour so when I turn up I can tell that I'm on my iPhone I can tell by my IP that I live in London because I know the time I'm in London I know the time of day in London I know what the weather is as I begin to browse through the site we start looking at behavioural data so I start clicking on certain things I can say oh it looks like this guy is interested in mountain bikes and headphones I'm going to show him content about that well it looks like this guy or people on iPhones tend to click on that banner and not that banner maybe the next person who's on an iPhone I'll show the banner that they click on and all of that we can all report on it all sits in the cloud it runs as a service integrated with Drupal so the workflow might be a turn up we can tell that this woman's come in she's clicked some pages, she's searched for some stuff she might have downloaded some documents so we know her behaviour we know her situation she's on a mobile device, she's in New York she feels in a form which gives us an email address so now if she comes back and we can link her against that email address but also we can start to look into other databases so if I've got a CRM if I've got some other place where I'm storing data about that user because we can now link her against your email we can see all of her history so we can figure out whether she's someone who's bought from us before or not if she is we'll show something different that's the idea so we want to try and capture as much data as we can about the user's journey on every touchpoint every data source and once we have that we can start doing stuff with it so from analytics kind of at the simplest level starting to do types of testing types of targeting we can also use the data in the database in other systems so it doesn't necessarily need to be Drupal that's displaying the results of that personalisation it could be like an email campaign or anything else you can just pull into the data via API and do things with it so you might have probably been victim of you visited a site and you've clicked on a whole bunch of stuff and you get an email the next day saying oh here you want to buy a new computer that's the kind of thing that Lyft can enable in a much better way there's also that Unified Visitor Visitor profile is reportable it sits in a scheme list database you can look at people visiting you can figure out what sort of people do what you can create dynamic segments so that after a user does define things they can fit into a segment which you can then use for further reporting or personalisation and like everything we try to do you can do that via the web we can do it via an API and so the idea is that you can do behavioural targeting or you can do A, B and N testing and it can get really big and complex personalisation is not a simple thing but the idea if we can keep really good data eventually we can come up with some really good insights and the longer we do it the better we get at it and I think Lyft is really good at that the architecture is set up in such a way that you can really get a lot of information about who your visitors are and the CMS aware way as well so it knows about the metadata and your site and knows about your information architecture so it can use a lot of that stuff that maybe a standard analytics package might not do so if we go back to this again with all those buzzwords when it makes a little bit more sense you can see this is where the things fit in so over here it's like BLT Pipelines Cloud Site Factory Drupal and Lightning Content Hub and then pushing it out across all of those devices and hopefully that all makes sense against the cycle it's always a challenge but we feel like we're getting there and I won't go into partners just on the basis of time but basically we can help you with this so we want to be a subscriptions company we don't want to sell services necessarily but what we do want to do is make sure that if you're using Drupal and you're using it in the best way so if you need some help we can provide that in lots of ways whether that's someone coming in and sitting beside you or whether it's someone on the end of the phone or if you're interested in the certification going on during Drupal Con for free so if you feel like trying one of the certification classes it will be worth checking so it's about time does anyone have any further questions you go yeah thank you how does it come when I would like to interface with the Salesforce for example do I need a developer do I need your support is there existing connectors want some access into the Salesforce database do I have a UI where I can pick up the fields that I need can I also enrich the Salesforce database with the information I have from the I would say to the valid position do you want to come in? so there's a couple of different ways that you can get information for itself the same way if someone registers to me you say hey this user has this email you can also send other information you might know about this person that's one way to get the information Drupal might know the other thing you can do enriching the visitor profile a lot of work that's going on you probably have to write so the API is open like you can go on our site docs.co.com, station API and read the API like there's no secret source there we will as time goes on have connectors in the same way we do for Content Hub as they come up we'll develop them and put them out there we probably have customers somewhere doing some kind of Salesforce integration but not in the way that we can put out there as a product that's been tested in all use cases yeah so you have a good cost to start adding on these other services how would they work incrementally yeah so the answer is I'm sure you can predict it depends a lot of this stuff a lot of the stuff I started with some of the other stuff like pipelines for example we're still nothing out in the details some of it will be just available for all customers immediately there'll be some other features that may not be but we're not quite sure exactly what they are Lyft is just about to launch a new version very soon Lyft 3 I'm not privy to the pricing about that but you might be number of unique visitors and number of decisions I think the model so if we have a client although they're big they're kind of putting money on HTML5 embeds and don't understand optimization that metrics very well is there a way to get them on to something Lyft has set up for that but I think it's not a freemium model you can't just turn it on there is an entry price but yeah I mean with the new launch we will be tearing it in such a way that you should be able to start something that you can demonstrate a way of value immediately as it adds more and more similarly with content hub it's based on the number of sites but it's not it doesn't matter how much content it's just sites I think so again it's a tiered model where you buy I've got 5 sites I've got 50 sites I've got 500 sites and it's a different tier but yeah swing by the booth and find a sales guy I'm sure you'll start telling you things anything else? anything else? so so first of all we love Travis we have a lot of customers who use Travis it's built into the Aquinas so one thing we do at Aquinas is we support the full stack of what you do with this infrastructure with the Portrait Code but we can't support your Travis CI configuration outside of the scope where you use pipelines plus we have partners they help you build as far as customers they were in situations where they would do a build that involved Travis CI which is great I guess that Travis CI is good they would hand off the build to the customer the customer would say hey this is a great site the customer doesn't know how to use Travis CI the customer starts calling up the partner and saying hey I'm having a problem a month or two later and the partner does not like this they don't want to get calls two months later so so basically there's other things that we can do that allow us to be more tightly integrated because we control the platforms for example there can be special commands in the ammo file for doing things like if you're on Travis and you like Travis a lot of the people who are in isolation will be able to do that well thank you very much so we probably need it today we probably need it today sure of course