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

      Cookieの設定

      弊社にとって、お客様のプライバシーを守ることと最適な体験を提供することは、どちらも大変重要です。弊社では、お客様に合わせてカスタマイズした情報を提供し、並びにアプリケーションの開発に役立てることを目的に、本サイトのご利用方法についてのデータを収集しております。

      そこで、お客様のデータの収集と使用を許可いただけるかどうかをお答えください。

      弊社が利用しているサードパーティのサービスについての説明とプライバシー ステートメントも、併せてご確認ください。

      サイト動作に必須:オートデスクのサイトが正常に動作し、お客様へサービスを提供するために必要な機能です

      Cookie を有効にすることで、お客様の好みやログイン情報が記録され、このデータに基づき操作に対する応答や、ショッピング カートへの商品追加が最適化されます。

      使用感が向上:お客様に最適な情報が表示されます

      Cookie を有効にすることで、拡張機能が正常に動作し、サイト表示が個々に合わせてカスタマイズされます。お客様に最適な情報をお届けし、使用感を向上させるためのこうした設定は、オードデスクまたはサードパーティのサービス プロバイダーが行います。 Cookie が無効に設定されている場合、一部またはすべてのサービスをご利用いただけない場合があります。

      広告表示をカスタマイズ:お客様に関連する広告が表示されます

      Cookie を有効にすることで、サイトのご利用内容やご興味に関するデータが収集され、これに基づきお客様に関連する広告が表示されるなど、効率的な動作が可能になります。また、継続的にデータを収集することで、お客様のご興味にさらに関連する広告を配信することが可能になります。Cookie が無効に設定されている場合、お客様に関連しない広告が表示される可能性があります。

      icon-svg-close-thick

      サードパーティのサービス

      それぞれの情報で弊社が利用しているサードパーティのサービスと、オンラインで収集するお客様のデータの使用方法を詳しく説明いたします。

      icon-svg-hide-thick

      icon-svg-show-thick

      サイト動作に必須:オートデスクのサイトが正常に動作し、お客様へサービスを提供するために必要な機能です

      Qualtrics
      弊社はQualtricsを利用し、アンケート調査やオンライン フォームを通じてお客様が弊社にフィードバックを提供できるようにしています。アンケートの回答は無作為に選んだお客様にお願いしておりますが、お客様から自発的に弊社にフィードバックを提供することも可能です。データを収集する目的は、アンケートの回答前にお客様がとられた行動を、より正しく理解するためです。収集したデータは、発生していた可能性がある問題のトラブルシューティングに役立てさせていただきます。. Qualtrics プライバシー ポリシー
      Akamai mPulse
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Akamai mPulseを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Akamai mPulse プライバシー ポリシー
      Digital River
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Digital Riverを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Digital River プライバシー ポリシー
      Dynatrace
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Dynatraceを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Dynatrace プライバシー ポリシー
      Khoros
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Khorosを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Khoros プライバシー ポリシー
      Launch Darkly
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Launch Darklyを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Launch Darkly プライバシー ポリシー
      New Relic
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、New Relicを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. New Relic プライバシー ポリシー
      Salesforce Live Agent
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Salesforce Live Agentを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Salesforce Live Agent プライバシー ポリシー
      Wistia
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Wistiaを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Wistia プライバシー ポリシー
      Tealium
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Tealiumを利用しています。データには、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Tealium プライバシー ポリシー<>
      Typepad Stats
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Typepad Statsを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Typepad Stats プライバシー ポリシー
      Geo Targetly
      当社では、Geo Targetly を使用して Web サイトの訪問者を最適な Web ページに誘導し、訪問者のいる場所に応じて調整したコンテンツを提供します。Geo Targetly は、Web サイト訪問者の IP アドレスを使用して、訪問者のデバイスのおおよその位置を特定します。このため、訪問者は (ほとんどの場合) 自分のローカル言語でコンテンツを閲覧できます。Geo Targetly プライバシー ポリシー
      SpeedCurve
      弊社は、SpeedCurve を使用して、Web ページの読み込み時間と画像、スクリプト、テキストなど後続の要素の応答性を計測することにより、お客様の Web サイト エクスペリエンスのパフォーマンスをモニタリングおよび計測します。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、お客様の Autodesk ID などが含まれます。機能のテストの結果によっては、お客様がご利用のサイトのバージョンが変わったり、サイトにアクセスするユーザの属性に応じて、パーソナライズされたコンテンツが表示されるようになる場合があります。. Google Optimize プライバシー ポリシー
      ClickTale
      弊社は、弊社サイトをご利用になるお客様が、どこで操作につまづいたかを正しく理解できるよう、ClickTaleを利用しています。弊社ではセッションの記録を基に、ページの要素を含めて、お客様がサイトでどのような操作を行っているかを確認しています。お客様の特定につながる個人情報は非表示にし、収集も行いません。. ClickTale プライバシー ポリシー
      OneSignal
      弊社は、OneSignalがサポートするサイトに広告を配置するために、OneSignalを利用しています。広告には、OneSignalのデータと、弊社サイトにアクセスしているお客様から弊社が収集する行動に関するデータの両方が使われます。弊社が収集するデータには、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID が含まれます。この情報に併せて、OneSignalがお客様から収集したデータを使用する場合があります。OneSignalに提供しているデータを弊社が使用するのは、お客様のデジタル広告体験をより適切にカスタマイズし、関連性の高い広告をお客様に配信するためです。. OneSignal プライバシー ポリシー
      Optimizely
      弊社はOptimizelyを利用して、弊社サイトの新機能をテストし、お客様に合わせた方法で機能を使えるようにしています。そのため弊社では、弊社サイトにアクセスしているお客様から、行動に関するデータを収集しています。収集するデータには、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID などが含まれます。機能のテストの結果によっては、お客様がご利用のサイトのバージョンが変わったり、サイトにアクセスするユーザの属性に応じて、パーソナライズされたコンテンツが表示されるようになる場合があります。. Optimizely プライバシー ポリシー
      Amplitude
      弊社はAmplitudeを利用して、弊社サイトの新機能をテストし、お客様に合わせた方法で機能を使えるようにしています。そのため弊社では、弊社サイトにアクセスしているお客様から、行動に関するデータを収集しています。収集するデータには、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID などが含まれます。機能のテストの結果によっては、お客様がご利用のサイトのバージョンが変わったり、サイトにアクセスするユーザの属性に応じて、パーソナライズされたコンテンツが表示されるようになる場合があります。. Amplitude プライバシー ポリシー
      Snowplow
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Snowplowを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Snowplow プライバシー ポリシー
      UserVoice
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、UserVoiceを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. UserVoice プライバシー ポリシー
      Clearbit
      Clearbit を使用すると、リアルタイムのデータ強化により、お客様に合わせてパーソナライズされた適切なエクスペリエンスを提供できます。弊社が収集するデータには、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID が含まれます。Clearbit プライバシー ポリシー
      YouTube
      YouTube はビデオ共有プラットフォームで、埋め込まれたビデオを当社のウェブ サイトで表示および共有することができます。YouTube は、視聴者のビデオのパフォーマンスの測定値を提供しています。 YouTube 社のプライバシー ポリシー

      icon-svg-hide-thick

      icon-svg-show-thick

      広告表示をカスタマイズ:お客様に関連する広告が表示されます

      Adobe Analytics
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Adobe Analyticsを利用しています。収集する情報には、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID、お客様の Autodesk ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Adobe Analytics プライバシー ポリシー
      Google Analytics (Web Analytics)
      弊社は、弊社サイトでのお客様の行動に関するデータを収集するために、Google Analytics (Web Analytics)を利用しています。データには、お客様がアクセスしたページ、ご利用中の体験版、再生したビデオ、購入した製品やサービス、お客様の IP アドレスまたはデバイスの ID が含まれます。このデータを基にサイトのパフォーマンスを測定したり、オンラインでの操作のしやすさを検証して機能強化に役立てています。併せて高度な解析手法を使用し、メールでのお問い合わせやカスタマー サポート、営業へのお問い合わせで、お客様に最適な体験が提供されるようにしています。. Google Analytics (Web Analytics) プライバシー ポリシー<>
      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、お客様の Autodesk 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

      オンライン体験の品質向上にぜひご協力ください

      オートデスクは、弊社の製品やサービスをご利用いただくお客様に、優れた体験を提供することを目指しています。これまでの画面の各項目で[はい]を選択したお客様については、弊社でデータを収集し、カスタマイズされた体験の提供とアプリケーションの品質向上に役立てさせていただきます。この設定は、プライバシー ステートメントにアクセスすると、いつでも変更できます。

      お客様の顧客体験は、お客様が自由に決められます。

      オートデスクはお客様のプライバシーを尊重します。オートデスクでは収集したデータを基に、お客様が弊社製品をどのように利用されているのか、お客様が関心を示しそうな情報は何か、オートデスクとの関係をより価値あるものにするには、どのような改善が可能かを理解するよう務めています。

      そこで、お客様一人ひとりに合わせた体験を提供するために、お客様のデータを収集し、使用することを許可いただけるかどうかお答えください。

      体験をカスタマイズすることのメリットにつきましては、本サイトのプライバシー設定の管理でご確認いただけます。弊社のプライバシー ステートメントでも、選択肢について詳しく説明しております。