AU Class
AU Class
class - AU

Web-Based Product Configuration Using Autodesk Forge Design Automation for Inventor

이 강의 공유하기

설명

Manufacturing companies are under increasing pressure to provide unique products to their customers, while simultaneously improving their overall efficiency. Getting sales and engineering working effectively together to efficiently produce accurate proposals for configurable products can be a challenge at the best of times. The current difficulties with finding and retaining staff, combined with increasing demand for product customization, make it even harder. This session will address the requirements, challenges, lessons learned, best practices, and value obtained from using Inventor models directly in a web-based configure-price-quote (CPQ) solution developed with the Autodesk Forge Design Automation API for Inventor software.

주요 학습

  • Learn how to structure Inventor models for use by Autodesk Forge.
  • Learn about the external interface and logic that must be developed to use Autodesk Forge effectively.
  • Learn about reference material available from Autodesk to start development of a configurator.
  • Learn about the components required for a complete configuration solution, from quotation to production.

발표자

Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      RYAN SMALL: Welcome to Autodesk University 2022 and this session titled Web-Based Product Configuration Using Autodesk Forge Design Automation for Inventor. This class is a case study, so we will not be diving too deep into technical details. But we'll point those that are technical to the appropriate resources. In this class, we will be sharing with you from our experience of building a product configurator on Forge using Inventor Design Automation.

      Let's review the learning objectives for this class. Firstly, we want to talk about some of the considerations for preparing your Inventor models to be used in Forge and specifically in vendor design automation. We want to talk about some of the user interface, the web UI components and logic that you need to develop and incorporate into your solution to use Forge effectively. We'll talk about some of the reference material available from Autodesk to help you get started in developing a configurator. And we'll talk about the components required for a complete configurator solution.

      So just a little bit about SolidCAD. So we are an Autodesk platinum partner. We've been a reseller for 25 years. We are based in Canada. We have 11 locations across the country and 150 or so staff spread across those locations. We are a Forge Certified Systems Integrator. We are Autodesk's largest reseller partner in Canada, and we're one of Autodesk's largest resellers in North America.

      So just a little bit about myself. My name is Ryan Small. I've been 22 years with SolidCAD, 23 years in industry. So almost the entire tenure of my life in the workforce has been here at SolidCAD. I did do a year as a full time AutoLISP programmer many years ago. I do have extensive experience with the Autodesk manufacturing products, primarily in Venture and Vault. I've actually worked with Vault from before it was an Autodesk technology as SolidCAD was a partner for [INAUDIBLE] Innovations that originally developed it. I've had a number of different roles here at SolidCAD, but presently today my official title is I'm Director of Software Development. Joining me today is my colleague Don Boresky.

      DON BORESKY: Thanks, Ryan. Yeah, my background is a pretty unique mix of technical expertise and business development in the software industry. The last 15 years, I've been in the Autodesk reseller channel, and prior to that, I worked with a variety of manufacturing and retail ERP systems. And while my formal education is very technical, I've always had a passion for viewing technology through the lens of business improvement, and that fits really well with my current role where I lead the business development efforts for SolidCAD's Configuration Solutions.

      RYAN SMALL: Thanks, Don. So as a company, we've had a long history of doing CAD-based development, add ins for products like Inventor or AutoCAD, Revit, et cetera. We decided a couple of years ago actually at Autodesk University 2019 that we were going to embark on the development of our own product configurator which really for us reflected our first product-based development. In the course of building that configurator, there's a number of things that we learned, some mistakes that we made, and so we're here to share really from that expertise to help you avoid some of those same pitfalls and hopefully help you in your path of building your own configurator.

      So why did we develop a configurator? So as a company here at SolidCAD, we have had a long history of working with customers doing product configuration on the desktop. We were actually a reseller for Logimetrix which was the company that developed the technology that is-- we now know today as iLogic which, of course, is native to Inventor.

      So in those course-- in the course of all of those years doing configuration on the desktop and working with customers to implement iLogic to help them to have configurable based design on the desktop, one of the questions that would often come to the surface in many cases is how do I move this configuration beyond the desktop so that people who are not designers, engineers, they have the ability to go ahead and do product configuration without having the knowledge of those CAD tools?

      There are, of course, other configurator products on the market. But one of the realities of many configurator solutions that are out there is that they require you to redo your design intelligence. So for companies that have made an investment into iLogic and Inventor, the fact that you've got to rebuild a lot of that stuff is not very appealing to somebody looking to move into a configurator.

      We also had some uncertainty about the future of Autodesk Configurator 360. We had seen over the course of time Autodesk invest in and divest of other configurator technologies-- Intent which was their flagship ETO product, Configurator One which we were actually a reseller for a couple of years. And so there was a little bit of uncertainty, and it did seem when we were really serious about building our own configurator that there was less fanfare, if you will, around Configurator 360 which made us a little bit uncertain.

      And of course, we had-- many of us here that were part of this had also seen many years ago Mechanical Desktop come and go. So we wanted to essentially go and build our own solution. We did. We did-- about five or six months after starting development, we did panic a little bit when Autodesk announced that C360 was being retired in favor of Forge because obviously, the development resources that we have at SolidCAD are much smaller by comparison to Autodesk. But Autodesk determined that Forge was really a platform. They weren't going to, at that point anyways, be part of the configurator product business, and so that kind of paved the way for us to continue to go forward in developing our own configurator.

      So Autodesk Forge is broken down into a number of different APIs, or we might just call them services. And there's certainly more than what are encapsulated on this slide. However, if you are looking to build a configurator using Inventor Design Automation on Forge, these four services really probably represent the cornerstone of your configurator solution.

      First and foremost is the Design Automation API. This is really Inventor running in the cloud. Now, there are other design automation APIs. There's AutoCAD, Revit and 3ds Max. Obviously, for the purpose of this class, we're going to be focusing on Inventor. Next is the Viewer API. This allows you the ability to view your file inside your web browser, and the file that you're viewing is a file that is a standard graphic format. So you're not needing any add ins or extensions in order to view that.

      The Data Management API or service is really where you're storing your data on the cloud. So more than likely, your configurator is going to make use of Inventor assets-- parts, assemblies, drawings, et cetera. Now, they've got to reside somewhere, so you can pass them into the Design Automation API. That place they're likely going to reside is in the data management service. That's your storage bucket for your data.

      And then you've got the Model Derivative service, and Model Derivative handles the conversion of your CAD data into something that is displayed in the viewer that we talked about. So that's handling translation of Autodesk formats like Inventor and AutoCAD, some third party formats, as well as some generic formats-- STEP and SAT and that sort of thing. Now, as much as these four services do represent the cornerstone of a configurator solution and certainly represented the four services that we initially utilized, we subsequently abandoned the use of Model Derivative API, and let's talk about why that was the case.

      So just to quickly recap, the Model Derivative Service is the component of Forge that's handling the conversion of your input file into SVF or scalable vector format which is a graphic file that you are going to display in the Forge viewer and ultimately on your website page. The problem that we ran into and actually spun our wheels on for quite some time has to do with an issue around suppression. So in Inventor on the desktop, you can mark components as suppressed which essentially unloads them from memory and from the display.

      And likewise, if you're building a iLogic-based design in Inventor, very common for users to employ that same methodology that you're going to turn on and off or suppress or unsuppress components based on the design requirements of the inputs you're specifying. The problem we ran into with Model Derivative is that when you send your Inventor file into Model Derivative to say I want to get this translated into SVF so I can display it in the viewer, it doesn't understand the concept of suppression. So the net result of that is that you end up with a resultant file that has all of the components displayed which means that you're no longer seeing an as-configured model.

      So if you look down here in the lower left of the slide, you can see kind of showing the two different paths. So if the valve on the left represents the configured model, when you pass that through the Model Derivative to say I want to prepare this to display in the viewer, you can see that all of the valve options are being shown. Why? Because Model Derivative does not understand suppression. So we were able to actually work with Autodesk to help determine an alternative solution which was to actually do the translation to SVF directly from Inventor. And the net result of that is we are able to have a model being displayed in the viewer that reflects our configuration model.

      There is another thing to consider even if you're not potentially dealing with suppression in Inventor. You may also want to think about doing the translation via Inventor Design Automation anyways just for the purpose of reducing some of your Forge cloud credit costs, simply because there is a cost to Model Derivative. It's one of the services you are paying for. Each time you do a translation, you are incurring some costs. So you may be very off further ahead by paying those costs towards the translation time in Inventor or Design Automation as opposed to paying the conversion costs via Model Derivative. So definitely something you're going to want to consider.

      So when we started down the path of building a configurator, as I mentioned, this was back in Autodesk University 2019 where our management team gathered together, actually, one of the tables outside the exhibitor hall. My development team was given a fairly limited runway to develop a working proof of concept. So what that meant was that at the time, we moved forward with our configurator based on the technologies that we knew. In retrospect, maybe weren't the best technologies kind of long term.

      So what that ended up meaning was over the course of time, after we built that proof of concept and we continue to build on that foundation of code, we got to a point where we actually kind of painted ourselves into a bit of a little corner. And we said, OK, to make this product more viable, we need to fix some of the core foundation of the product. So we actually ended up doing two fairly major code overhauls where, in both cases, we went through swapping out existing technologies for other technologies that were more suited to where we wanted to go.

      So thinking about what we would have done differently, if we could go back in time, I think I would say if after we develop that proof of concept and we were able to sort of convince our management this was a path to continue down on, I think at that point, I would have said, OK, we did the rapid prototype. We used what we knew, but let's take a step back and build a more solid plan, determine what are the right languages and technologies or frameworks to build on that are going to be scalable for the future?

      Do we need to bring in some different resources to augment because maybe we didn't have the staffing on that we needed for the right technologies that we thought were suitable to move forward. And maybe that meant possibly even abandoning all of our rapid prototype code and starting new from that foundation. So if you're in a position where you're able to establish a plan from day one, definitely think about what's the right scalable technologies, what's the resources. If you do find yourself in a similar situation where you have to come up with a proof of concept, maybe it makes sense to start with what you know, but maybe that's not the right path for the future kind of big picture.

      In thinking about expertise and skill set, just be aware you're going to have to obviously have expertise in a few different areas. Obviously, you're going to have to have web development expertise and of course, expertise with Inventor. Now, one of the things I'll maybe just caution is that if you are competent with iLogic, I mean, if you're the iLogic power user, just be aware that there's still a learning curve for you to move to Inventor Design Automation and Forge.

      iLogic is a great on ramp to configuration, but with it targeting maybe a non-programmer, but when you do get into Inventor Design Automation or Forge in general, it is kind of working more on the basis of the fact that you are a developer. And so you just need to kind of be aware of that. Obviously, you're going to have to have familiarity with Forge. That's probably stating the obvious. But it is a new set of services you've got to be able to wrap your head around. There's documentation and tutorials, et cetera. We'll talk about some of those resources later.

      You may, depending on your solution, and again, this is really a question of scalability footprint of your solution where you're going with configurator for. You may or you may not need to have a DevOps or infrastructure resource. Maybe this is somebody who's an expert in technologies like Amazon Web Services or Microsoft Azure. Again, just depending on your scalability, that's something you're going to want to consider as part of your solution.

      So I know thinking about us with our configurator, we have people who are experts on the web development side, experts on the Inventor side, and then experts on Amazon Web Services, so-- kind of filling all those pieces. So just some things to think about as far as resources. One last comment I'll make on this slide. If you're looking to build a solution as a configurator solution, if you're already experienced in .NET, especially if you're coming from Inventor already, I would probably be inclined to try to do as much as I can in the .NET space just so that you're kind of working in one language.

      In our case, we're not. We are, obviously, a team of multiple people, but it's something I would at least consider if you're a .NET developer today and you know Inventor. And the reason for that is the fact that when you deal with your Inventor add in, you're going to be writing it and .NET anyways, so it might make sense just to keep everything under one technical space.

      So thinking about your configurator solution, and to be honest, this is something we sort of learned the hard way in a couple of cases. You're going to want to think about engaging with your end users and probably involving them early in the process and depending on your solution, possibly as an ongoing. It's important that you work with your end users to really validate your workflow. Developers, especially if you are a developer or if you've worked with a developer, sometimes think how to move forward and implement something that might not be the best for especially somebody who's not technical.

      So you definitely want to think about engaging your end users, making them part of the process so that you're sure that it's going to be as easy to use product as possible. This becomes really important if your solution, if your configurator solution is going to be public facing where you might not have the ability to train the people who are going to be using your configurator. So you really want to think this through.

      As I mentioned, we sort of learned this ourselves through just some experiences. So we actually had two different scenarios that come to mind. So the first thing we did was when we built our configurator, and I'll show the video here to sort of illustrate the before and after of how we made the changes, we were getting feedback almost immediately from end users that they didn't know what to do in step two. You'll see when I play the video that the essence of our configurator is you specify your inputs, and you would go ahead and generate a model that users would then scratch their head saying, well, what's the next step?

      To us as developers, it was obvious. Oh, you go over here and click this tab. To the end user who had never seen the solution before, they scratched their head. The other thing we ended up doing as well is when we-- in our configurator, we had combined initially two different actions together, those actions being the generation of the model, which you see in the viewer, as well as the resultant downloads like the quote document, the PDF of that configuration, some of the DMG files, et cetera. We combined all of that into one option or one activity.

      The net result was is that it was just introducing a little bit of a performance, some negative performance, because a lot of times users were, in many cases, they just wanted to validate visually, first of all, whether this was the right design that they wanted before initiating the process of creating the downloads. And interestingly, as we've looked at customer analytics, we can actually see and we track it in our logs the fact that, yes, indeed. Customers many, many times over will run a configuration multiple times, and then they'll say, yes, this is actually the reflective of the design. So we ended up separating those two tests.

      So let me go ahead and play the video. I'll show you-- which I'll show you the before and after. So let me go ahead and click on play here. So this is our solution initially before we made the changes. So the user would go in. They'd specify their configuration options, and we would go ahead and click Generate. So again, as I mentioned, we were combining together the creation of the file for the viewer which we're going to display on screen and the downloads. And so we'll just wait here for a sec. You'll see there, obviously, is a little bit of a delay. When we see the app, you'll see this process much quicker as we've sort of separated the tasks.

      But the users after they did the model wouldn't know to go and click this tab. So they didn't know what step two was, and step two is really the heart of all of the good data that you're getting out-- your quote, your downloads, et cetera. So what we did is we changed it. So same as before, we go specify our product input options. We click Generate Model, which is now very specific that, hey, we're creating the model. We're not worrying about creating all the downloads. This allows users to quickly determine is this what I want.

      If in fact, it is, they initiate the second task of creating the downloads. And as we'll see here in a minute, when the downloads are created, we just automatically flip over to the Downloads tab. So the user no longer has to scratch their head saying, well, what's the next step here? So it's almost complete. There we go. We've auto activated. So it really made the end user experience a lot more clear and again, especially because our solution was targeting people that we weren't going to be able to train.

      So since the expectation or likelihood is that you're going to be looking at implementing a configurator on Forge from the basis of Inventor data or using Inventor data as your input, be aware that you are likely going to have to do some tweaking, if you will, to your Inventor designs for a couple of reasons. One is the fact that you need to make sure that your designs are able to be modified without blowing up. If you change a constraint value in a design and that causes constraint errors, that's not a good candidate yet to take it to design automation.

      As well, you need to think about what the range of configurability is. So perhaps when you modeled a plate, you created a square. You created a circle, and then you ended up having a hole in the plate by virtue of just not selecting the circle input. Well, that's a problem if in your configuration you need to turn off the hole feature. So that may mean you have to actually put the hole as a separate feature in your design so that you can have something to turn on or off.

      So you need to just be thinking about what-- how appropriate are these designs to be able to move forward into Inventor Design Automation? The key thing is Inventor Design Automation, really like Inventor on the desktop. It can only modify a design to the degree that you can do it manually. So if you can't pick and click in Inventor and get that design to work correctly without causing problems, it's not going to work in iLogic on the desktop. It's not going to work in Inventor Design Automation. So you want to make sure those data sets are pretty clean.

      The other thing is, there are some specific Inventor Design Automation things that you do need to think about. The link is there. I'm not going to go to the link because the link is fairly technical. We're trying to keep things fairly high level here. So especially somebody who's a developer, you're going to want to go check some of those details out because it does get into the weeds a little bit. But one that's very simple and straightforward to explain and is key is that interactivity is not allowed in Inventor Design Automation on Forge.

      So things like message boxes, input boxes, they will cause issues. They'll cause the Inventor Design Automation activity to fail. So you need to think about that. So in many cases, like I'll show in the video here-- I'll just go ahead and hit play-- this is a simple rule in iLogic that's basically, say, telling the user if they haven't put the right length value in or they've gone to high that we're going to show a message box. That's fine on the desktop, but it's not any good in Inventor Design Animation.

      So as the video simply shows here I'll play, sometimes this is just as simple as going, selecting those lines in the iLogic editor, and just commenting those lines out. So you can still have your rule. You just need to make sure you suppress or comment those lines of code just so that you're not going to get into any issues when you get into Design Automation.

      So let's just talk a little bit about the Forge workflow here, and this is obviously specific around the idea of Inventor Design Automation. So you're going to have your web UI. That's where the user is going to pick their configuration options, essentially the parameters, what their selections are. You're going to package that data up. You're going to send it over to Forge, and you're basically sending to Forge your parameter options from your UI as well as, of course, your Inventor model.

      That's going to be processed by Inventor Design Automation. It's going to essentially take the input parameters, pump those into the Inventor model, and essentially leave you with a model that reflects your configuration. Now, from here, it's going to obviously produce the result, and the result is going to be a configured model which you're going to display likely in the Forge viewer. So you get that visualization file, and maybe you're also including as part of your output some additional downloads.

      Now, with that workflow in mind, the key thing that you need to realize is Inventor Design Automation is not interactive. So if you have familiarity with iLogic in Inventor or even if you happen to have experience with Configurator 360 in the past, it's very different because we're not dealing with interactivity in Design Automation. So there are a couple key things that you need to then be aware of and think about in your configurator solution.

      So the first one is you need to possibly, again, depending on your models, you need to implement some logic via the user interface, especially if you've already got some of that logic in your model that may not transfer well. So I'll go ahead and play the video and just talk through this. You'll see pretty clearly what I'm driving at. So let me go ahead and hit play. So this is a simple iLogic model in Inventor. It's got two parameters, width and length.

      They're both dropdown parameters, but what happens is that the way this model works is that my length parameter is restricted based on the value of my width. So if width is one to five, my length can only be one to five. But if it's greater than five, I can have a length of one through 10. And that's easily implemented through just a simple iLogic rule that says if the width is less than or equal to five, these are the options for length. Otherwise, these are the options.

      Because Inventor Design Automation is not interactive, you need to make sure you account for that logic via your UI. So one of the things that we ended up having to build into our solution is the ability to let users essentially clone a parameter and then control the visibility of that parameter using display conditions. So in this case, I've duplicated length. We just have a little UI bug we've got to sort out which is that the new parameter that we copy always gets added to the top. So I'm just going to reorder this so my two links are beside each other.

      So we're going to go to the length. You'll see here always on is disabled. That gives us access to a display condition. So this is basically controlling when this parameter gets shown in our interface. So we're going to say that if the width is less than or equal to five, we want the parameter be shown, and these are the available length options that are available.

      We're going to go to the other length parameter which, again, is duplicate parameter. We're going to turn always on off, and we'll set another display condition. This one is a display condition that is greater than or equal to six because this now has a wider range of options. So I'm just going to go ahead and add in some additional parameter values here just to add in the list of parameter options. I'm entering the value in twice because the value on the left is what you're displaying to the user and the interface, and the value on the right is what's actually being passed as the parameter.

      So you could, for example, on the left, if you want to actually write the word and then the number on the right. So we'll go ahead and save our parameter. So again, just to recap, we've got one width parameter, one-- or pardon me, two length parameters. Width is always on because obviously, that needs to be there. But in our two length parameters, which are identical to each other in terms of the parameter name, however, are different because in both cases they have different input options to select which are tied to the selection of our width.

      So if we go ahead and save all that, we'll jump over the configurator. Here we are with width. So again, you see the input option we've selected. You can see the lengths are one to five. Makes sense. Our width is only one. If we jump to a value of six, we're dynamically turning on and off parameters. We now have the option one through 10. We jump to five, and we're back to a limited set of parameters.

      The other thing you're going to want to do is make sure that you're providing users feedback. When you send your activity to Design Automation in order to configure the model and produce the outputs, there's going to be a delay there while the Inventor instance spins up, and your data is passed over and executed and such. So because of that and because it's not directly interactive, you need to make sure that you're incorporating feedback to your end users. Let them know what's going on. Keep them engaged within the process.

      So you see here, I'll go ahead and click play here on this video. So same as before, we're going to go set our parameter options as desired, and we'll go and click on Generate here in just one moment. And as soon as we go ahead on it, on Generate, you'll see there we are giving the users live, dynamic feedback letting them know exactly where we are. Just, again, keeps them engaged, lets them know we're working on this, and that they're not refreshing their browser or wondering what's happening. So definitely a couple of things you're going to want to consider with incorporating into a solution, just this whole idea of Inventor Design Automation not being interactive.

      Now, this may apply to a limited set of people, but it's something worth considering. And this is the idea whether or not you want to go with a single or multi-tenant infrastructure. So let's maybe just sort of clarify what this is, what's meant by this. So if you are a single tenant infrastructure, what that means is that each client or customer has their own Forge application. So there's kind of that layer of isolation inherently defined.

      On the other hand, if you have a multi-tenant application, then you may have multiple clients, multiple users, potentially multiple companies. They're accessing the same Forge application. So what are some of the considerations, or what's the sort of pros and cons to consider when you're trying to make a decision? So if you go with single tenant, you're going to have to have a bigger investment in infrastructure.

      Why? Because you need to be able to scale up your solution and bring other tenants online. And that's going to require creation of new websites and that sort of thing deployment, of your code, et cetera. There is some benefit to single tenant. You are reducing your downtime risk because each client or company, they're kind of running in isolation through containerization. So if you have a virtual server for customer A and it goes down, that virtual server for customer B would stay operational.

      One of the downsides, though, of single tenant is that you're going to have to leverage and/or write custom code to handle the deployment of your code to those tenants, both your web code and your Inventor Design Automation plugin. Now, I can speak from experience, this is something we didn't do for a while until we got to a point where it just became extremely time consuming for us to go ahead and update customers. And it actually was pretty quick that we ran into just a lot of headache because supporting multiple Inventor versions, needing different code for those Inventor versions across different customers would mean that it could take hours for us to update the code either on the web side or on the Inventor add in side.

      So if you are looking at dealing with a larger number of tenants or even a smaller number where you think, hey, there's some concern here about the frequency of pushing things out and getting them updated, it's something you're going to want to think about. On our side, we use Amazon's AWS CodePipeline to push out our web code, and we actually wrote a custom tool to push out the Inventor add in. So when we make changes to our configurator, we can very quickly push those-- push that code out across all our tenants fairly easily.

      There is some benefit if you do need to track Forge costs on a per customer basis, single tenant is helpful because you're going to be creating one Forge app for every customer. So it's very easy to go into the dashboard and determine what those costs are. If we look at the other side of the coin, multi-tenant, you've got one code base. So even if you are doing your code updates manually, which would probably be the case, you're only updating it once. So it's pretty straightforward.

      It is a single point of failure. So if that app goes down or the server goes down, essentially everybody's locked out until it's operational again. If you do need to track Forge costs because you can't rely on the Forge dashboard reporting, you'd have to write some code to track those costs. So client A is logged in. They're running a job. These are the Forge credit usage, so you incorporate that into your own dashboard.

      And lastly, you may need to implement security or segregation via code. So a classic example would be if you have a product configurator that you've built that you're making your products that you manufacture available online. Maybe you've got a distributor network, and certain distributors can only configure certain products. Or maybe certain configurators or certain distributors, pardon me, have different pricing structures available just because of the volume that they sell. You would obviously have to make sure that you implement that via code to make sure the distributors are only seeing their respective data.

      So we spent some time walking through some of the challenges that we ran into, try to help you avoid running into the same pitfalls. What we want to do is kind show you the-- really, just the essence of what our configurator solution is that we ended up building that encapsulates all of these ideas. And with that, I'm going to go ahead and turn it over to Don.

      DON BORESKY: Thanks, Ryan. I'm going to take a look at Variant from the perspective of our approach to the market and clients. When we started the Variant project, we decided to focus on some key target characteristics that we thought were underserved. And first, we decided to focus on the configure-to-order space versus engineered order, and this enabled us to develop a pretty light application that effectively leverages Forge.

      We also focused on organizations whose products can be configured in one model using iLogic. Not to say the products have to be simplistic, and as you can see from the examples I've included on the slide on the right, the products can be quite complex. And lastly, we focused on organizations with the discipline to manage configurations but didn't want to invest in traditional configurator solutions. There's lots of very capable configuration systems out there, but they've typically been very expensive and difficult to implement. We wanted to make Variant different on both fronts.

      So this focus has created a unique value proposition for the organizations that we work with. By leveraging Forge, our clients are able to use their existing iLogic code rather than rebuild product rules in a separate sales-focused system. By using Forge and AWS, we're able to maintain an entirely web-based infrastructure enabling clients to extend configuration to whoever and wherever they want on virtually any device. And by hiding all the complexities of Forge and AWS behind one simple annual subscription, we keep the implementation uniquely easy to manage and scale up.

      To bring all this together, I'll take a quick tour of one of our client's implementations of Variant. Vent-A-Hood is an 80-year-old innovator in the kitchen range hood industry. You might recognize them as one of the early adopters and signature accounts for Autodesk Configurator 360. Vent-A-Hood's public facing Build-A-Hood configurator is now driven by SolidCAD Variant. Now, because Vent-A-Hood products can be specific to regions, we start by picking the area that we're in, and this provides access to all the configurable hoods. Each of these is an iLogic-driven Inventor model.

      Let's take a look at the JCH/A1. When we pick the model, the website links to the Variant tenant for that configuration. Now, as mentioned, all the configuration parameters and valid options are directly drawn from the Inventor model and displayed on the left. Let's pick a width, and we'll grab a CSM or CFM, sorry. I kind of like the stainless steel finish, and we'll take the option for a couple of bands. And we see that additional parameters to define the details of the bands are now added. As Ryan referred to earlier, Variant in this case has been configured to prompt for band details only when the number of bands is not zero.

      So I'll select the band style and whether or not there are bands on the duct cover and the band finish. And once we've defined the options we want, we hit Generate Model. Variant and Forge now do their thing. Variant packages up the selected parameters, sends them to Forge to generate the configuration. Because the model is already uploaded to Forge as part of the initial setup process, only the parameters themselves need to be passed.

      Forge applies the parameters to the model and sends back the result. And while Forge is doing its thing, as Ryan mentioned earlier, we're providing feedback so users know the process is running, and they can stay engaged. When it's done, the updated configuration is displayed in the Forge viewer. If further changes are needed, we can update the parameter selections and rerun Generate Model as often as we need. But when you have the result you're looking for, we hit Generate Downloads.

      Forge is then reengaged to generate the additional documents and files related to the configuration in this case. Now, Vent-A-Hood has given their users the options to download a couple of different model formats, 3D and 2D DWGs, PDF drawing, and request a quote for the configuration. While Vent-A-Hood isn't using it, Variant also has options for additional downloads such as the configured Inventor model and an actual priced out quote document. Ryan, that covers the highlights, so back over to you.

      RYAN SMALL: OK, great. Thanks, Don. So in wrapping up, where do you go next? So this is probably going to depend on your role. So if you're a developer, I would probably start with the Forge Developer Portal at forge.autodesk.com. This is really the primary resource for documentation tutorials and support. You may also want to consider participating in one of the Forge accelerators. So these are in-person events where you are working closely with Autodesk experts and Forge to help build out your solution.

      And I will actually state, when we were in the early days of building out our configurator, we did actually participate in the week-long Forge accelerator. So we are-- we're testaments, I guess, if you will, to going down that path. You're also going to want to be aware of the Autodesk Sample Application. There's two links there. The first link takes you to the live version which is just the ability to essentially use the demo of that configurator. But the second link is to the source code, so you can go to GitHub and grab that code. It will get you pointed in the right direction with a pretty decent foundation of code.

      If you're an executive or manager, you're going to want to make sure you think about securing the right resources. Possibly that's having developers on staff. Maybe you need to augment with some external partners, some web development companies, some system integrators for Forge. You need to make sure that you've got the right expertise at the table to be able to develop a solution. And of course, you may want to evaluate whether or not you want to build your own. Certainly, if you are, I would recommend using the source code that's available in GitHub or other products in the marketplace for product configuration.

      If you have any questions, we'd love for you to reach out. You can see the respective emails for myself and for Don. So please don't hesitate. Send us an email. We'd love to hear from you. And with that, thank you very much.

      ______
      icon-svg-close-thick

      쿠기 기본 설정

      오토데스크는 고객의 개인 정보와 최상의 경험을 중요시합니다. 오토데스크는 정보를 사용자화하고 응용프로그램을 만들기 위해 고객의 본 사이트 사용에 관한 데이터를 수집합니다.

      오토데스크에서 고객의 데이터를 수집하고 사용하도록 허용하시겠습니까?

      오토데스크에서 사용하는타사 서비스개인정보 처리방침 정책을 자세히 알아보십시오.

      반드시 필요 - 사이트가 제대로 작동하고 사용자에게 서비스를 원활하게 제공하기 위해 필수적임

      이 쿠키는 오토데스크에서 사용자 기본 설정 또는 로그인 정보를 저장하거나, 사용자 요청에 응답하거나, 장바구니의 품목을 처리하기 위해 필요합니다.

      사용자 경험 향상 – 사용자와 관련된 항목을 표시할 수 있게 해 줌

      이 쿠키는 오토데스크가 보다 향상된 기능을 제공하고 사용자에게 맞는 정보를 제공할 수 있게 해 줍니다. 사용자에게 맞는 정보 및 환경을 제공하기 위해 오토데스크 또는 서비스를 제공하는 협력업체에서 이 쿠키를 설정할 수 있습니다. 이 쿠키를 허용하지 않을 경우 이러한 서비스 중 일부 또는 전체를 이용하지 못하게 될 수 있습니다.

      광고 수신 설정 – 사용자에게 타겟팅된 광고를 제공할 수 있게 해 줌

      이 쿠키는 사용자와 관련성이 높은 광고를 표시하고 그 효과를 추적하기 위해 사용자 활동 및 관심 사항에 대한 데이터를 수집합니다. 이렇게 데이터를 수집함으로써 사용자의 관심 사항에 더 적합한 광고를 표시할 수 있습니다. 이 쿠키를 허용하지 않을 경우 관심 분야에 해당되지 않는 광고가 표시될 수 있습니다.

      icon-svg-close-thick

      타사 서비스

      각 범주에서 오토데스크가 사용하는 타사 서비스와 온라인에서 고객으로부터 수집하는 데이터를 사용하는 방식에 대해 자세히 알아보십시오.

      icon-svg-hide-thick

      icon-svg-show-thick

      반드시 필요 - 사이트가 제대로 작동하고 사용자에게 서비스를 원활하게 제공하기 위해 필수적임

      Qualtrics
      오토데스크는 고객에게 더욱 시의적절하며 관련 있는 이메일 컨텐츠를 제공하기 위해 Qualtrics를 이용합니다. 이를 위해, 고객의 온라인 행동 및 오토데스크에서 전송하는 이메일과의 상호 작용에 관한 데이터를 수집합니다. 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 이메일 확인율, 클릭한 링크 등이 포함될 수 있습니다. 오토데스크는 이 데이터를 다른 소스에서 수집된 데이터와 결합하여 고객의 판매 또는 고객 서비스 경험을 개선하며, 고급 분석 처리에 기초하여 보다 관련 있는 컨텐츠를 제공합니다. Qualtrics 개인정보취급방침
      Akamai mPulse
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Akamai mPulse를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Akamai mPulse 개인정보취급방침
      Digital River
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Digital River를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Digital River 개인정보취급방침
      Dynatrace
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Dynatrace를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Dynatrace 개인정보취급방침
      Khoros
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Khoros를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Khoros 개인정보취급방침
      Launch Darkly
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Launch Darkly를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Launch Darkly 개인정보취급방침
      New Relic
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 New Relic를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. New Relic 개인정보취급방침
      Salesforce Live Agent
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Salesforce Live Agent를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Salesforce Live Agent 개인정보취급방침
      Wistia
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Wistia를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Wistia 개인정보취급방침
      Tealium
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Tealium를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Upsellit
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Upsellit를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. CJ Affiliates
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 CJ Affiliates를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Commission Factory
      Typepad Stats
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Typepad Stats를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Typepad Stats 개인정보취급방침
      Geo Targetly
      Autodesk는 Geo Targetly를 사용하여 웹 사이트 방문자를 가장 적합한 웹 페이지로 안내하거나 위치를 기반으로 맞춤형 콘텐츠를 제공합니다. Geo Targetly는 웹 사이트 방문자의 IP 주소를 사용하여 방문자 장치의 대략적인 위치를 파악합니다. 이렇게 하면 방문자가 (대부분의 경우) 현지 언어로 된 콘텐츠를 볼 수 있습니다.Geo Targetly 개인정보취급방침
      SpeedCurve
      Autodesk에서는 SpeedCurve를 사용하여 웹 페이지 로드 시간과 이미지, 스크립트, 텍스트 등의 후속 요소 응답성을 측정하여 웹 사이트 환경의 성능을 모니터링하고 측정합니다. SpeedCurve 개인정보취급방침
      Qualified
      Qualified is the Autodesk Live Chat agent platform. This platform provides services to allow our customers to communicate in real-time with Autodesk support. We may collect unique ID for specific browser sessions during a chat. Qualified Privacy Policy

      icon-svg-hide-thick

      icon-svg-show-thick

      사용자 경험 향상 – 사용자와 관련된 항목을 표시할 수 있게 해 줌

      Google Optimize
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Google Optimize을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Google Optimize 개인정보취급방침
      ClickTale
      오토데스크는 고객이 사이트에서 겪을 수 있는 어려움을 더 잘 파악하기 위해 ClickTale을 이용합니다. 페이지의 모든 요소를 포함해 고객이 오토데스크 사이트와 상호 작용하는 방식을 이해하기 위해 세션 녹화를 사용합니다. 개인적으로 식별 가능한 정보는 가려지며 수집되지 않습니다. ClickTale 개인정보취급방침
      OneSignal
      오토데스크는 OneSignal가 지원하는 사이트에 디지털 광고를 배포하기 위해 OneSignal를 이용합니다. 광고는 OneSignal 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 OneSignal에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 OneSignal에 제공하는 데이터를 사용합니다. OneSignal 개인정보취급방침
      Optimizely
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Optimizely을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Optimizely 개인정보취급방침
      Amplitude
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Amplitude을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Amplitude 개인정보취급방침
      Snowplow
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Snowplow를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Snowplow 개인정보취급방침
      UserVoice
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 UserVoice를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. UserVoice 개인정보취급방침
      Clearbit
      Clearbit를 사용하면 실시간 데이터 보강 기능을 통해 고객에게 개인화되고 관련 있는 환경을 제공할 수 있습니다. Autodesk가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. Clearbit 개인정보취급방침
      YouTube
      YouTube는 사용자가 웹 사이트에 포함된 비디오를 보고 공유할 수 있도록 해주는 비디오 공유 플랫폼입니다. YouTube는 비디오 성능에 대한 시청 지표를 제공합니다. YouTube 개인정보보호 정책

      icon-svg-hide-thick

      icon-svg-show-thick

      광고 수신 설정 – 사용자에게 타겟팅된 광고를 제공할 수 있게 해 줌

      Adobe Analytics
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Adobe Analytics를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID 및 오토데스크 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. Adobe Analytics 개인정보취급방침
      Google Analytics (Web Analytics)
      오토데스크 사이트에서 고객의 행동에 관한 데이터를 수집하기 위해 Google Analytics (Web Analytics)를 이용합니다. 여기에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 오토데스크는 사이트 성과를 측정하고 고객의 온라인 경험의 편리함을 평가하여 기능을 개선하기 위해 이러한 데이터를 이용합니다. 또한, 이메일, 고객 지원 및 판매와 관련된 고객 경험을 최적화하기 위해 고급 분석 방법도 사용하고 있습니다. AdWords
      Marketo
      오토데스크는 고객에게 더욱 시의적절하며 관련 있는 이메일 컨텐츠를 제공하기 위해 Marketo를 이용합니다. 이를 위해, 고객의 온라인 행동 및 오토데스크에서 전송하는 이메일과의 상호 작용에 관한 데이터를 수집합니다. 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 이메일 확인율, 클릭한 링크 등이 포함될 수 있습니다. 오토데스크는 이 데이터를 다른 소스에서 수집된 데이터와 결합하여 고객의 판매 또는 고객 서비스 경험을 개선하며, 고급 분석 처리에 기초하여 보다 관련 있는 컨텐츠를 제공합니다. Marketo 개인정보취급방침
      Doubleclick
      오토데스크는 Doubleclick가 지원하는 사이트에 디지털 광고를 배포하기 위해 Doubleclick를 이용합니다. 광고는 Doubleclick 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Doubleclick에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Doubleclick에 제공하는 데이터를 사용합니다. Doubleclick 개인정보취급방침
      HubSpot
      오토데스크는 고객에게 더욱 시의적절하며 관련 있는 이메일 컨텐츠를 제공하기 위해 HubSpot을 이용합니다. 이를 위해, 고객의 온라인 행동 및 오토데스크에서 전송하는 이메일과의 상호 작용에 관한 데이터를 수집합니다. 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 이메일 확인율, 클릭한 링크 등이 포함될 수 있습니다. HubSpot 개인정보취급방침
      Twitter
      오토데스크는 Twitter가 지원하는 사이트에 디지털 광고를 배포하기 위해 Twitter를 이용합니다. 광고는 Twitter 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Twitter에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Twitter에 제공하는 데이터를 사용합니다. Twitter 개인정보취급방침
      Facebook
      오토데스크는 Facebook가 지원하는 사이트에 디지털 광고를 배포하기 위해 Facebook를 이용합니다. 광고는 Facebook 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Facebook에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Facebook에 제공하는 데이터를 사용합니다. Facebook 개인정보취급방침
      LinkedIn
      오토데스크는 LinkedIn가 지원하는 사이트에 디지털 광고를 배포하기 위해 LinkedIn를 이용합니다. 광고는 LinkedIn 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 LinkedIn에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 LinkedIn에 제공하는 데이터를 사용합니다. LinkedIn 개인정보취급방침
      Yahoo! Japan
      오토데스크는 Yahoo! Japan가 지원하는 사이트에 디지털 광고를 배포하기 위해 Yahoo! Japan를 이용합니다. 광고는 Yahoo! Japan 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Yahoo! Japan에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Yahoo! Japan에 제공하는 데이터를 사용합니다. Yahoo! Japan 개인정보취급방침
      Naver
      오토데스크는 Naver가 지원하는 사이트에 디지털 광고를 배포하기 위해 Naver를 이용합니다. 광고는 Naver 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Naver에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Naver에 제공하는 데이터를 사용합니다. Naver 개인정보취급방침
      Quantcast
      오토데스크는 Quantcast가 지원하는 사이트에 디지털 광고를 배포하기 위해 Quantcast를 이용합니다. 광고는 Quantcast 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Quantcast에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Quantcast에 제공하는 데이터를 사용합니다. Quantcast 개인정보취급방침
      Call Tracking
      오토데스크는 캠페인을 위해 사용자화된 전화번호를 제공하기 위하여 Call Tracking을 이용합니다. 그렇게 하면 고객이 오토데스크 담당자에게 더욱 빠르게 액세스할 수 있으며, 오토데스크의 성과를 더욱 정확하게 평가하는 데 도움이 됩니다. 제공된 전화번호를 기준으로 사이트에서 고객 행동에 관한 데이터를 수집할 수도 있습니다. Call Tracking 개인정보취급방침
      Wunderkind
      오토데스크는 Wunderkind가 지원하는 사이트에 디지털 광고를 배포하기 위해 Wunderkind를 이용합니다. 광고는 Wunderkind 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Wunderkind에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Wunderkind에 제공하는 데이터를 사용합니다. Wunderkind 개인정보취급방침
      ADC Media
      오토데스크는 ADC Media가 지원하는 사이트에 디지털 광고를 배포하기 위해 ADC Media를 이용합니다. 광고는 ADC Media 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 ADC Media에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 ADC Media에 제공하는 데이터를 사용합니다. ADC Media 개인정보취급방침
      AgrantSEM
      오토데스크는 AgrantSEM가 지원하는 사이트에 디지털 광고를 배포하기 위해 AgrantSEM를 이용합니다. 광고는 AgrantSEM 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 AgrantSEM에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 AgrantSEM에 제공하는 데이터를 사용합니다. AgrantSEM 개인정보취급방침
      Bidtellect
      오토데스크는 Bidtellect가 지원하는 사이트에 디지털 광고를 배포하기 위해 Bidtellect를 이용합니다. 광고는 Bidtellect 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Bidtellect에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Bidtellect에 제공하는 데이터를 사용합니다. Bidtellect 개인정보취급방침
      Bing
      오토데스크는 Bing가 지원하는 사이트에 디지털 광고를 배포하기 위해 Bing를 이용합니다. 광고는 Bing 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Bing에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Bing에 제공하는 데이터를 사용합니다. Bing 개인정보취급방침
      G2Crowd
      오토데스크는 G2Crowd가 지원하는 사이트에 디지털 광고를 배포하기 위해 G2Crowd를 이용합니다. 광고는 G2Crowd 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 G2Crowd에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 G2Crowd에 제공하는 데이터를 사용합니다. G2Crowd 개인정보취급방침
      NMPI Display
      오토데스크는 NMPI Display가 지원하는 사이트에 디지털 광고를 배포하기 위해 NMPI Display를 이용합니다. 광고는 NMPI Display 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 NMPI Display에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 NMPI Display에 제공하는 데이터를 사용합니다. NMPI Display 개인정보취급방침
      VK
      오토데스크는 VK가 지원하는 사이트에 디지털 광고를 배포하기 위해 VK를 이용합니다. 광고는 VK 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 VK에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 VK에 제공하는 데이터를 사용합니다. VK 개인정보취급방침
      Adobe Target
      오토데스크는 사이트의 새 기능을 테스트하고 이러한 기능의 고객 경험을 사용자화하기 위해 Adobe Target을 이용합니다. 이를 위해, 고객이 사이트를 방문해 있는 동안 행동 데이터를 수집합니다. 이 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역, IP 주소 또는 장치 ID, 오토데스크 ID 등이 포함될 수 있습니다. 고객은 기능 테스트를 바탕으로 여러 버전의 오토데스크 사이트를 경험하거나 방문자 특성을 바탕으로 개인화된 컨텐츠를 보게 될 수 있습니다. Adobe Target 개인정보취급방침
      Google Analytics (Advertising)
      오토데스크는 Google Analytics (Advertising)가 지원하는 사이트에 디지털 광고를 배포하기 위해 Google Analytics (Advertising)를 이용합니다. 광고는 Google Analytics (Advertising) 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Google Analytics (Advertising)에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Google Analytics (Advertising)에 제공하는 데이터를 사용합니다. Google Analytics (Advertising) 개인정보취급방침
      Trendkite
      오토데스크는 Trendkite가 지원하는 사이트에 디지털 광고를 배포하기 위해 Trendkite를 이용합니다. 광고는 Trendkite 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Trendkite에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Trendkite에 제공하는 데이터를 사용합니다. Trendkite 개인정보취급방침
      Hotjar
      오토데스크는 Hotjar가 지원하는 사이트에 디지털 광고를 배포하기 위해 Hotjar를 이용합니다. 광고는 Hotjar 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Hotjar에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Hotjar에 제공하는 데이터를 사용합니다. Hotjar 개인정보취급방침
      6 Sense
      오토데스크는 6 Sense가 지원하는 사이트에 디지털 광고를 배포하기 위해 6 Sense를 이용합니다. 광고는 6 Sense 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 6 Sense에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 6 Sense에 제공하는 데이터를 사용합니다. 6 Sense 개인정보취급방침
      Terminus
      오토데스크는 Terminus가 지원하는 사이트에 디지털 광고를 배포하기 위해 Terminus를 이용합니다. 광고는 Terminus 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 Terminus에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 Terminus에 제공하는 데이터를 사용합니다. Terminus 개인정보취급방침
      StackAdapt
      오토데스크는 StackAdapt가 지원하는 사이트에 디지털 광고를 배포하기 위해 StackAdapt를 이용합니다. 광고는 StackAdapt 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 StackAdapt에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 StackAdapt에 제공하는 데이터를 사용합니다. StackAdapt 개인정보취급방침
      The Trade Desk
      오토데스크는 The Trade Desk가 지원하는 사이트에 디지털 광고를 배포하기 위해 The Trade Desk를 이용합니다. 광고는 The Trade Desk 데이터와 고객이 사이트를 방문하는 동안 오토데스크가 수집하는 행동 데이터 모두에 기초하여 제공됩니다. 오토데스크가 수집하는 데이터에는 고객이 방문한 페이지, 시작한 체험판, 재생한 동영상, 구매 내역 및 IP 주소 또는 장치 ID가 포함될 수 있습니다. 이 정보는 The Trade Desk에서 고객으로부터 수집한 데이터와 결합될 수 있습니다. 오토데스크는 디지털 광고 경험에 대한 사용자화를 개선하고 고객에게 더욱 관련 있는 광고를 제시하기 위해 The Trade Desk에 제공하는 데이터를 사용합니다. The Trade Desk 개인정보취급방침
      RollWorks
      We use RollWorks to deploy digital advertising on sites supported by RollWorks. Ads are based on both RollWorks data and behavioral data that we collect while you’re on our sites. The data we collect may include pages you’ve visited, trials you’ve initiated, videos you’ve played, purchases you’ve made, and your IP address or device ID. This information may be combined with data that RollWorks has collected from you. We use the data that we provide to RollWorks to better customize your digital advertising experience and present you with more relevant ads. RollWorks Privacy Policy

      정말 더 적은 온라인 경험을 원하십니까?

      오토데스크는 고객 여러분에게 좋은 경험을 드리고 싶습니다. 이전 화면의 범주에 대해 "예"를 선택하셨다면 오토데스크는 고객을 위해 고객 경험을 사용자화하고 향상된 응용프로그램을 제작하기 위해 귀하의 데이터를 수집하고 사용합니다. 언제든지 개인정보 처리방침을 방문해 설정을 변경할 수 있습니다.

      고객의 경험. 고객의 선택.

      오토데스크는 고객의 개인 정보 보호를 중요시합니다. 오토데스크에서 수집하는 정보는 오토데스크 제품 사용 방법, 고객이 관심을 가질 만한 정보, 오토데스크에서 더욱 뜻깊은 경험을 제공하기 위한 개선 사항을 이해하는 데 도움이 됩니다.

      오토데스크에서 고객님께 적합한 경험을 제공해 드리기 위해 고객님의 데이터를 수집하고 사용하도록 허용하시겠습니까?

      선택할 수 있는 옵션을 자세히 알아보려면 이 사이트의 개인 정보 설정을 관리해 사용자화된 경험으로 어떤 이점을 얻을 수 있는지 살펴보거나 오토데스크 개인정보 처리방침 정책을 확인해 보십시오.