AU Class
AU Class
class - AU

The Conceptual Design Process framework: from the raw idea to the digital model

이 강의 공유하기
동영상, 발표 자료 및 배포 자료에서 키워드 검색:

설명

The class will guide attendees to understand the principles and aim of the Conceptual Design Process developed for White Architects, and the benefits that Autodesk technology and services can bring.

White Architects needed to identify design intent in conceptual architecture stages, including energy efficiency. They wanted to use Autodesk applications to efficiently identify the design intent and, at the same time, to be able to re-use the digital models in later design processes.

Autodesk has worked with them to define the best processes and tools to achieve their objectives, defining a consistent framework that allows White architects to use the framework as a fluid and flexible tool for facing this early stage design and to use the digital models downstream to accomplish with more advanced phases of the project lifecycle.

주요 학습

  • Understand the specific features and challenges of the conceptual design stage
  • Identify the design intent and the related set of scenarios
  • Use a conceptual model to perform energy analysis
  • Configure the conceptual design phase using the developed framework

발표자

  • Fouad Khalil
    Fouad is now VP at GA Studio- prior to that he was a practicing architect at White Arkitekter's Linköping office where he also served as Creative Director.He spends much of his time focusing on the areas of building technology and performance, particularly as they relate to sustainability, energy performance and analysis and facade design.These areas are intimately tied in to use of the technology toolset and the use and implementation of these tools and the relationship to design methodology is another area of active interest as well.
  • Paolo Galli 님의 아바타
    Paolo Galli
    I'm an architect based in Rome (Italy), with 15 years of experience in BIM; I started working for Autodesk in 2005 as an Autodesk Authorized Consultant and eventually I joined the Company in 2012 as a member of Autodesk Consulting, on the EMEA BIM Transformation Team. I'm experienced on BIM transformation and implementations, Revit guru and enthusiast; I put many energies on shaping an architectural oriented set of services, taking advantage of Autodesk applications with the BIM approach adding a bit of "out of the box" thinking. I had the opportunity to develop a framework to approach the Conceptual Design Process, involving a number of Autodesk tools and driving the adoption by means the definition of a set of consistent processes and best practices. During my spare time I still continue dealing with BIM (I'm an enthusiast, you know), playing basketball, driving my motorbike and strumming my ukulele.
Video Player is loading.
Current Time 0:00
Duration 1:01:12
Loaded: 0.27%
Stream Type LIVE
Remaining Time 1:01:12
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
Transcript

PAOLO GALLI: You know, I'm Italian. I'm supposed to be in loud and noisy and whatever and make a lot of a gestures with the hand, but a microphone helps in these cases. By the way, there are a lot of slides so I'll try to be as quick as possible. We will go through these points. So an initial boring introduction. So we try to understand together-- we will try to tell you our point of view about what conceptual design is. Where is architecture? Interesting point, a strange question, actually.

The CDP Framework, conceptually same process, and what happened in White Architects and some ideas, some brainstorming about the future steps. OK, let's start. Some rules. You will be ours for the next 60 minutes. OK, if you don't want to switch off your mobile phone you can just mute them, but if you want to use them, you are allowed just to tell great is this session. Thank you for being here. Enjoy the travel of ideas. Let's get conceptual and let's start.

Oh, other questions. How boring. Why this presentation? Why are we here? I don't know if you've noticed, but here at AU, we saw a lot of great presentations about engineering services, advanced stuff and whatever. But here, we are here to discuss about conceptual design and architecture, so this presentation is because every project starts with a sketch, because we need to create a bridge and fill the gap between pencil and pixels. We are architects, or at least I suppose many of you are architects, and we are a creature of habit. The design is not just a set of drawings or a model or whatever.

The designer is a large lifecycle, so we need to deal with that. We must create and add value, because we are architects. We know we have a big responsibility on the future of other people. We need to add value. And last but not least, we want to have fun again. We want to have fun from being an architect. OK, second production.

FOUAD KHALIL: I'll just introduce myself. My name is Fouad Khalil, I was the technical lead on the White side for this project, and from I think 2012 to '17 I was Creative Director at White in Linkoping at the Linkoping office and also served as an IT Methodology leader. And I'm no longer with White. I'm currently at another firm, but I'm presenting from White. I just actually switched jobs a few weeks ago.

So my presentation will focus more on the technical implementation of the conceptual design solution. So where I think Paolo will frame the larger picture, what I'd like to do is give you a sense of what we did, what our kind of metrics were, what the process was, and the result. And that'll be the second half of the presentation.

PAOLO GALLI: And this is me. Paolo Galli, Italian. I think you've noticed that. I have a background as an architect. I joined Autodesk five years ago, almost six actually, but the past 12 years, I would say even 15 in some cases, implementing BIM, dealing with Revit and horsing around the BIM and Revit, all this stuff. What I'm doing. I'm belonging to the BIM Transformation Team [INAUDIBLE]. Well, I work mostly in Europe. My competencies are more related to BIM implementation but with the architecture flavor.

I had the opportunity to work on business development activities, shaping a solution, solution offering definition, creation or standard procedure, whatever whatever. OK, I don't want to bore you reading all the lines. I have a Master in architecture in Rome. I also studied in Spain and in Argentina. That's it I will be boring you for the next 20, 25 minutes. So that's it. What is the conceptual design process?

Oh, interesting question, because what is conceptual design? Just some questions. I don't know the answers. But just some questions I want to share with you. Modeling for fine things, optimizing, creating, evaluating scenarios, decision making, sketching, conceptual design. What is conceptual design? Is it massing? Revit massing, FormIt? Oh, I don't know if I can say it. SketchUp. Being that I'm an expert or at least I'm supposed to be, people usually ask me, Paolo, what do you think is the best tool to do conceptual design?

What is the best conceptual design tool? Woah, good question. SketchUp. No, well I mean, it's hard to tell, because I still haven't understood what conceptual design is. And so I can tell you what's my best-- or in my opinion for doing conceptual design-- you know, I'm an Autodesk man, so you can imagine what my answer is. I can also show you-- oh, this. Great tool, beautiful, absolutely beautiful.

I'm still an architect, so when I have a new design to approach, instead of opening the computer or taking the paper, the white paper-- big issue or the worst enemy of the architect, the white paper. I take my ukulele. I love ukulele. Only four strings, the right number of strings, I think. And the world would be a better place if everyone would play the ukulele. But wait, I start playing, and I imagine to be on the shore of Maui listening to the waves on the sand. And so this way, I leave my brain free to think.

Free to think, free not to think to the conceptual design, to the tool, to the project. I want my brain to be free. So the point is, conceptual design is not a tool. It's something more. And let's go through. I have some questions, again, some keywords I would say. Again, these are keywords just to help us to think about what conceptual design is. I found very useful for me, for myself at least, thinking about these words. So obviously, conceptual. Responsibility. I love our book from Renzo Piano, The Responsibilities of Architect.

We are designing the future of other people. Ideas. Intent, the design intent. Scenarios, defining vision, giving a vision. Out of the box. Thinking, not taking everything for granted. Iteration, reuse, structure verses flexible, interesting. What is architecture and where is architecture? Oh, this is my mistake. I wanted to write where. I wrote what. But where is architecture? Actually, just imagine the project lifecycle.

We have a large lifecycle for the project in which at the very beginning, we the architects are supposed to look for scenarios, responding and completion with the requirements, trying to satisfy what the requirements want to solve with the architecture. So we are there to find a shape, to find scenarios, to find a solution. But after a solution has been chosen, the degrees of freedom decrease, because obviously once we've chosen that specific shape of a specific scenario, well adding LOD-- I mean, level of definition or liberal of development-- to the project, we lose the possibility to make major changes.

This is just to say that maybe the most of the effort of the architect is at the very beginning in the concept phase, because it's there that you can give the footprint and guiding the project on a specific rail, a specific direction. This means that we have a big responsibility, because we are feeding technology requirements with use requirements with architectural requirements. All the downstream uses, all the other disciplines, we have a big responsibility. So this is my estimation based on my experience.

The degrees of freedom, so the amount of effort of an architect maybe is 80% on the concept, 15, 20 on the preliminary detail. Well, during the detail design, we can decide the material, finishing some small details, but we cannot change so much of the project. We cannot give a large footprint. This has been already given. And over zero, maybe. Obviously, for transformation, this life cycle begins again. What's happened? Conceptual design. Every project begins with a sketch.

Actually, I notice that there are a lot of sketches on the internet done by famous architects, and this means that maybe sketch art is still an important part of our job, at least at the very beginning. This is Michelangelo, this is Palladio, Rogers, Renzo Piano, [INAUDIBLE]. The worst enemy of the designer, of the architect, the white paper. Once you have your white paper in front of you or you have a ukulele, and this will help you, otherwise it will be very, very hard. And this obviously requires coffee, just to be clear, and it's a very important part. But the point is we are in 2017.

We should understand what is a sketch, what a sketch means during the BIM era. And I think this is a quite important question. Is this a sketch? Is this a sketch? A digital sketch? Now, I don't know. Is this a sketch? Starting with clay models, forgetting, using photogrammetry, digital models. Is this a sketch? I'm not giving you the answer. I don't know the answer. I'm still investigating it. But I want to share with you my experience and this process, the growth process, because again, I do believe that we have a strong responsibility as an architect.

The big misunderstanding. About one year ago, I think Fouad, we had the opportunity to start working with White architects in Sweden, and we were supposed to investigate our technology to see how, in which degree, we were able to help White architects to approach the conceptual design. And we started thinking about a typical set of activities based on a timeline, describing what that conceptual design process is. And what happened is that we understood that this was a big misunderstanding, because thanks to the interaction and discussion we had with White architects, we understood that the conceptual design is not a linear process.

A process is defined as the set, the sequence of rational activities with the aim of transforming some input in output. And this is something different, because we have a linear sequence or task in a standard production process, while for conceptual architects, conceptual design, we have a nonlinear iterative framework. Typically, a process wants inputs to be transformed to output, but while here we have transformation of requirements to scenarios. OK, scenario can be an output, it's just semantic. Just try to understand the deep meaning of that.

Clear roles and responsibilities on one hand and fluid and flexible set of roles and responsibilities for conceptual design. It's not always so clear once you have to find the idea, the design intent, identify what you are going on. It's very difficult giving specific stuck roads, fixed roads. This is an important point. The design development is based on an existing design. Here, the design doesn't exist yet. We need to find the design intent, and the design intent, the idea, is the main output. Little change is allowed, large change is expected.

High LOD, low, very low LOD. It's still BIM. We need to understand that the level of definition of an element is very low. This means that many changes are expected, and we need to act in consequence. OK, just an image. CDP substrate, substrate design process substrate. Other key words or sentences just to help you but help me, actually, to better understand this point. What we learned is that we need to change lenses often. It's like a camera. So we need to move from general to particular to general to particular. I mean, trying to see the project from different angles often, continuously.

Keywords-- communicate, speak, have arguments, fight. It's not a peaceful process, the conceptual design process. And often big friendship goes out during this process. But OK, we have a nonlinear process, again. Use non-standard approaches. For this reason it was very hard trying to understand how to use a process for describing something which is not a process. Mix digital and analogic methods. The Bucket and the Funnel, what is that? OK, bucket, funnel. We identified a couple of components, conceptual components. We have a funnel which is a filter which drives ideas in a specific direction, and we have below a bucket, which is a blind container.

Actually, my first impression with conceptual design is having a bucket in which I put ideas, I mix them together, I keep out and see what's happening. Oh, I like, I don't like. Maybe I need to mix them all something more. So some key words here, again, the funnel is often related to analysis, tool of the task with the aim of understanding or evaluating or reviewing. The bucket the something related to massing, sketching, brainstorming, mistakes and whatever. Try to think out of the box.

This is another keyword we learned, another sentence we learned. And do not take anything for granted. It's not just a production process. I suppose you know this is a pie chart. OK, great. What we did-- what we learned is that having a linear process is a big misunderstanding. We have more than a linear process. We have like a gear, a mechanism, in which we have an external gear, an external engine pushing the movement. It doesn't depend on us. External decisions, requirements or whatever.

And we have a set of internal decisions represented by another big mechanism which is a gear composed of three wheels, and this is the approach we developed together. These three wheels are representing-- in the center the output, and the three rings, the three wheels inside the gear represent a set of components, of solution components. The first one touching the outside gear is the analysis. Then, we have co-creation. I love co-creation, this word. That this is something White uses. This means collaborative creation, and it's great. It's a great word, I think, for representing what we are doing with conceptual design.

And then something related to the analysis. Again, the idea here is that each wheel is composed as an orange of segments. Each segment belongs to the specific wheel, and connecting these segments in a specific way can help us to shape a path for solving a specific conceptual design. These are the segments we went through with White. Let me go to the next slide, because I think this helps you to better understand what we did. Imagine that in this mechanism, we have an internal mechanism composed of other small gears. On the outside, we have all the main stuff, the main activities related to the analysis.

Before I told you this is not a process, it's a framework. But obviously, we need to bring some order, some standardization. So the idea is instead of standardizing the whole process, we standardize the pieces, the small pieces, the micro uses of our information models. Depending on the way we connect these pieces, we can shape a different path for solving different issues. Imagine we have an internal refurbishment of an existing building. We are not interested on context analysis, maybe, because I only have to organize the internal space.

So this segment won't be involved, won't be included. What are-- and this is a sample path, just to say. We can connect different segments, we can take the documentation and the structure and the tools for completion with the segment. These help me also to use the right set of people, to select the right team, because it's very clear. And next, what are the issues here? Is that the main components of the solution is the set of solution components, the segments, and the interface resolution when data moved from a segment to another.

And this interface obviously changes if data are moving in this direction or on the other. Some possible paths we defined for solving specific aspects of the design. OK, there's something very Autodesk, but I'm proud of this scheme. This has been developed by my former manager Brian Lopez, and it defines the BIM use. What's a BIM use? We are using the naming convention given by Penn State University. The BIN use is the use you do of an information model, the scope, the final scope of an information model. And for a BIM use, you always have some data, input and output, a process for transforming this data, and obviously a technology system, the software.

For this reason, we define each segment as a micro BIM use. Each segment-- so context creation, space analysis, volume studies, energy analysis, [INAUDIBLE] and whatever, graphical production-- we define all these segments, all these small pieces as micro-BIM uses. So for each of them, we define the scope, just to understand why we need that specific segment or not. What are the data? I, O, input and output involved, what's the process, and what are the involved tools? And the same for interfaces. We try to define how solve interfaces in order to better understand what could be the most seamless way for moving data from a segment to another in terms again of data process and in this case people, because different people with different roles or different skills have to speak in this case.

This is the conceptual architecture we defined for the regional solution. Obviously now, something is changed, because we don't have anymore ReMake. We have ReCap photo, now. But OK, the main aim remains. As you can see, the conceptual architecture is based on both local and cloud services in order to allow to use standardized software but also to design everywhere and give to people the possibility to access the models everywhere anytime. This is the standard organization we gave to the documentation, so all the set of documents have this very same organization. This means that if you need to understand a specific aspect of a single segment, you know that you will always have the documentation split and organized in the same way.

And these are the high level description of all the segments belonging to the tree wheels. Analysis-- and we think, we define that with White-- that the set of 11 segments we defined can help to approach pretty much all kinds of conceptual designs, architectural designs. So we have context creation, special-- oh, this is not creation. It should be analysis. My mistake. Area analysis, performance analysis. I mean, all helps you to understand the initial situation but also to evaluate an existing model, because remember the path. The path can go to the co-creation and can come back to be evaluated.

The same for co-creation. We have the Hands Back Process. The Hands Back is an interesting segment we created, and the meaning is give me the possibility to use again my hands. So give me the possibility to feel the bridge between pixels, a pencil and pixels. So help me to understand how to use the pencil, the clay or whatever for feeding the digital models. And for this, we involve the sketchbook, Revit, ReCap, and all the stuff allowing us and helping us to give a more human interface to the process.

Space planning-- the segment involved on the definition on how to create a floor plan distribution but for that later will give us more details. And OK, I don't think it's interesting commenting all the segments, because there are 11 segments and I know I am boring you. Visualization-- there's an interesting segment here, process of visualization. It's the segment helping me to create a process for capturing a design shape. And the set of properties of a specific design, it needs during its lifecycle just to demonstrate what was the path followed for achieving that result and to help also the people, the people team to learn for the next time on how a specific design has been developed in order to reuse that experience or correct some issues.

For each segment, we define the possible interfaces. So for the context analysis, for the space planning or whatever, we define what, where? The segments feeding with data or the possible segment feedings with data, the space planning or the specific segment, and the segments fed by the current segment, because remember the scheme, it's very, very important solving these interfaces, because interfaces are a crucial, critical part while shaping your solution, your project organization. That's it. Fouad? I'm sorry to have bored you, but I like speak, and when I give a public, it's terrible to me.

FOUAD KHALIL: Thanks, Paolo. OK, so just a little context here. It's little faint, but this was a co-collaborative process launched with Autodesk and White. So I should introduce White to you. White Arkitekter is an interdisciplinary practice for architecture, urban design, landscape architecture, and interior design. Embedded in the work of White is a commitment to sustainability in all its forms, underpinned by practice based research. As a collective of 900 employees organized in networks across 15 offices in Sweden, Denmark, Norway, and the United Kingdom, White works with clients and consultants to create inclusive, resilient architecture that inspires sustainable ways of life.

I think it's kind of one of the interesting features about White-- and it has to do with the Nordic context-- is that the work there is intensely collaborative and quite open. Teams tend to be very horizontal and multidisciplinary. We have a lot of specialists working at White, and one of the ways we try to tap into the expertise with the specialists is the workshopping process, which is really essential. And it's quite normal, actually, in the Nordics to workshop public sector, private sector, I mean really across all segments. And that was a key aspect of how we went about setting this up.

This is just some of the work I was involved with. This is the student center in Linkoping which is under construction now. This was not the candidate project we chose. After we had worked on the workshops, we chose a this project, which was a competition for a kind of a college and mixed use development in Linkoping This is a public space in front that resulted out of the competition effort. We used the competition to launch the technical solution for the conceptual design, so it's really important that we prototyped the conceptual design toolset while we were actually doing an actual project so that we could drill down the segments, get them to work, and also test case them in an actual project environment.

We didn't want to just stop this with an off the shelf solution that nobody was really going to be able to use. Obviously, this presented some challenges, but I think at the end we were quite pleased with the result. So just a little bit on the project. This is a couple of the boards that came out of this. This is a project for Kungsberg School, which is a school in Linkoping. It's actually more of a college and vocational school. It's a mixed use development as well, so it's two blocks, 80,000 square feet of education and totaling about 250,000 square feet or the equivalent in meters. I'm American now, so I've lost the metric.

It's got office, retail, involved a large urban planning component, and a significant architectural component. And this project, basically the production time on this was about, I'd say, less than two months using the tool set. And so it was a very, very kind of a Scrum-based, very, very fast development. And we were able to use the solution effectively to get there. So features of the solution that we wanted to implement-- we really needed to tightly track program area requirements through all phases of this conceptual design. So competition briefs in Sweden are actually binding, and it's very easy to get disqualified.

There's a big culture of architectural competitions in the Nordics, but the requirements tend to be quite strict, and you can be disqualified for something like going over on a science program area. So it's very, very important for us that we track program areas throughout and we maintain a very tight envelope around the program areas. We really wanted to be able to harmonize the graphic output. So for example, we needed the solution to track exactly a plan section, exploded acts on, tables, we needed-- the colors are a little faint, but something like color control where we're tracking the exact value of the color for our program areas and across all this kind of output was something that was really important. We really wanted to have one model to output all of the work.

That was really essential. So what we didn't want to have is a visualization model that was done by one team and a programming model that was done by another and another set of information that was running the bubble diagramming process. We needed actually all of that to be tightly woven. So everything you see on these two boards was output from the exact same model, and that was really a key feature. It basically meant that we were slow in the beginning and very fast at the end. The other thing that we were trying to do-- and this kind of goes back to the inclusive culture-- is that we didn't want this to be just a team of early adopters. It actually had to be implementable across multiple skill levels for our team.

So everything from a senior project manager who didn't have a lot of Revit experience or wasn't really into working with models but tended to work with things like program areas or Excel spreadsheets, to your production people who may be somewhat savvy, to your early adopter who's also working on the team. So it was important in the workshopping process to identify each kind of user case need and try to build a tool around that. So what we kind of ended up with here are three tracks, three parallel tracks that are going on during conceptual design in this case. And the track-- we had the BIM track, which is the generation of the building information.

We had the management and programming track, which basically is tracking these program areas and making sure that the functional requirements are met. And we had the exterior track, which is modeling the exterior scan, and the overall massing and then testing that against the program and the functional requirements. So these three things are being launched and developed at the same time. And then the tool set that we used involved Excel, FormIt, AutoCAD, Revit, 3D Studio, Dynamo, and the Creative Suite. And that's where really we were helped a lot by Autodesk and the expertise they brought helping us knit these pieces together.

That's really what kind of created this coherent solution. So what you see that's really key here that's a big part of this is in the management track, we represent that basically with an Excel spreadsheet. So if you can imagine you've got a program that's coming in from a client or it's being generated internally, that's just a simple spreadsheet that's being used to run the data for the project. And we actually-- since that's often the case, we had that Excel resource drive the data back and forth from something like the bubble diagram back to the Excel for validation to the initial massing study. Again, that gets pushed out back to the Excel file for check, and then that's used to develop more and more detailed outputs both for the design and then for the ultimate for visualization output or basically the graphics.

So we're using this as a storehouse of the data and making sure that's the control. This keeps everything consistent. Meanwhile, these things are developing along and they're basically being used to check against with the Excel file. So just to get into that, our first segment, really what we wanted to explore was early massing but basically bubble diagramming the functional spaces. So we have the massing and the exteriors is developing on a separate track, so we have the overall form and the urban design for the project.

We used a program called Gephi, which is an open source program for bubble diagram. It's very easy to use and it's free, and we used that to develop the bubble diagram. That is using data that's being brought in from the initial Excel file. And then we're using FormIt, this was our first foray into FormIt, to develop the overall massing. And the spaces are developed in the bubble diagram mode, and then the results being exported back to the Excel, as I said. So just a quick look at the FormIt. So this is really kind of where I started working.

So myself and a couple of colleagues or using FormIt to develop the initial sketches. This is one of the initial studies, and we really liked FormIt. I don't know, how many people here are familiar with the FormIt tool? Yeah, I thought it was really fun to use. I enjoyed using it. It's got its kind of clicks, you know, it's got its unique things, but in terms of interoperability and some of the functionality we needed to use very quickly, the FormIt tool was really successful. We really liked the geolocation, the Revit portability, we liked that we're able to bring in Sketchup, we really, really loved the gross area at a glance.

This was really invaluable, so being able to select and understand what your gross area is when you're in the initial modeling phase at a click, that helps a lot. And it keeps you from needing to use a CAD file to track your area separately, which we didn't want to do. And then the levels. So being able to assign levels and have those levels port into your Revit model, that was really great too. Again, at a glance, areas by level-- as the model developed and we're able to pull those, we know floor by floor what's going on, that was really great. If any FormIt developers are here, the ability to assign a department or a use and be able to kind of drill down on your square footages and get so much to this assigned area, so that would be even better.

So assigning a parameter to some of these volumes and then being able to subdivide your gross totals would be even awesomer. So that's going on. In the meantime, our team is using this Gephi program to get the spaces firmed up. And so what you're looking at here is the Gephi interface and the solution, so you can play with this tool pretty easily. Everybody on our team got oriented and was using it on their own. It's really not very hard to use, and we have documentation on how to bring in Excel and develop bubble diagrams in Gephi for anybody interested. But you see there at the corner is our-- I think we've got a shot of the Excel file.

It also has-- there's an Excel file, and then this is kind of the Gephi equivalent. So it has a tabular way to track square footages. And then this is all kind of linked to the table. So all of this is to scale and it's correct, and you can assign colors for your departments in the same way you would in a diagram. So once after that Gephi development gets going, we're exporting the result back to the Excel as a simple CSV. There's nothing fancy about that. But in the next stage, what we really wanted to do was import that information into Revit and start setting up block diagrams like basically stacking diagrams.

And we wanted to have the color controlled centrally, so we didn't want every team members setting their own colors, because that actually sounds really silly, but that ends up wasting a lot of time if you make the wrong mistakes. And we needed to track that in a schedule, so the schedule was preset in a template. So Autodesk helped us develop a template where all these resources were really primed and ready. All we had to do is get the data in. So this is the file we used to instantiate. This is basically taking the data-- this is the script file in Dynamo-- it takes the data from the Excel file and generates simple boxes that can be manipulated to create stacking diagram in 3D.

We also were following a standardized method for developing the scripts so that this could be shared across the entire firm and everybody would always know how to use the scripts, and that had to do with developing an annotation. You know, there's just a standard for annotation, a standard for user input, and then trying to describe the basic steps as groups, as colored coded groups. And what this allowed us to do during training was actually get new users under the hood and begin to orient them to Dynamo and what Dynamo can do without really intimidating them too much about worrying about the individual nodes. You can just kind of understand how the process is unfolding in the script without having initial knowledge, any real knowledge of Dynamo.

And then the second fill- and we kind of broke it down into scripts. So we didn't want one script doing all the work. We wanted to have bit-sized pieces. So the second one basically applies the color. It looks to the Excel file, actually, is where we set the colors, and then it colors by department according to the Excel file. So this is the result here. So you get this kind of array of area boxes that are stretchable. They're all color coded according to the colors that are set in the Excel file by the manager, the digital or the virtual manager. That's a little tab in the Excel file where you can set colors, and it just runs a little macro that says, these are the RGB values, now read these RGB values and apply those to all the areas with this parameter in the group.

And then your data is populating into the parameters of the boxes. So you can do things like get totals, track what the target area is versus the actual area once you begin stretching, that was really important. So that's kind of the first step. And then we have this schedule preloaded, and it's got a conditional format. So if your areas start to deviate, say, greater than 5% of what the target is, it starts flagging it red. And that's preloaded, so nobody has to mess with the setting that up. It's already in there. As soon as they create, they can get the read on where they are. Once they're finished with the stacking diagram, we take that data and export it back to the Excel, so we have a running track record at every stage of how is the area, how are we doing at this stage?

How are we doing on the next? And that's just a script that creates a new tab in the Excel file with the updated information, so that Excel file's always current, and it has a historical memory. So in this segment, we needed to start taking the stacking diagram and actually create assets or outputs for presentation. So this script was kind of amazing. For me it's an amazing script, because it actually automates-- we actually used furniture families to create those boxes, and the reason why is we wanted to be able to just use a family that we could just kind of hide or eliminate or put on a workset and close that wasn't like a generic model.

But we need to go to rooms and walls and annexed and actual building objects in the next stage. So this initial script will take the block diagram, and it will develop-- well, let's see here. I'm getting ahead of myself. But basically, we're creating floors, walls, and rooms, from the stacks, from the initial furniture families. The only problem we had was we couldn't actually add the interior wall. It only creates the exterior envelope with the building, but it will place the rooms centered on each program block. So once you start populating your interior rooms, your rooms kind of snap into position. They're all there.

So just kind of give you an idea before and after. So on the top, you have the program stack, and you see the-- that's kind of a plan output showing the furniture families. Once we run the script, there are floor slabs and exterior walls that are automatically put in, and then rooms are actually automatically placed. But they're all overlapping, so once you just add the interior, and you can do that by tracing over that with an interior wall, all of the rooms kind of start snapping into place. And again, color codes tracked, we have tags developed so we can see what the area of each room is.

A lot of really simple things, but when you aggregate them and you're using them at speed, it helps out a lot. And then once again, after we do this we still needed-- because we're adding corridors now, we're still making adjustments-- once we get to the end of that phase, we want the data exported back to the Excel for tracking. And we're doing the same thing. We have instead of a furniture schedule, we now have a room schedule with the same conditional formatting so we can see where we're over or under. And then this script here will take it back to the Excel file and create another tab that shows you where you are at this point.

And then finally, developing final assets for presentation. So the exterior model is pulled in to the final drawings. Final views are created for rendering mock up and production, and there's another script which takes the resulting areas and creates a final block diagram as a generic model. In this case, we really wanted our exploded axonometric diagram to really track, literally track exactly the areas. So it uses the rooms to create the blocks and not the initial furniture families, because those are now obsolete. So this is some of the output.

You can see that the floors are color coded, and they're again set by the Excel file. So we use just the same file to drive the color coding here. We create these block diagrams through the script, and it's also color coded, and we can do exploded axons or whatever. We're also driving the exterior renderings. This was actually using the FBX export or FBX link, which we found actually to be really effective. So my rendering colleague, he's looking-- I mean, I'm setting the view up for him, I've also got the materials assigned-- and he's just using the FBX to apply maps and develop the rendering straight from my model.

We're not doing a third model or rendering model at all. And then getting this tabulated is pretty straightforward. You've got the information in Excel. You can format that now from your Excel data, and it's all correct. It's literally what you've tracked in your Revit model, because you've just exported to Excel. So just maintaining that tight data integrity throughout the process all the way to the final boards. And that's basically the solution. So just a couple of notes. Again, the collaboration process at White's really essential, and we welcome collaborators. If you're interested in these resources, we have the educational resources and the scripts available, and we're happy to share with anybody.

I can't give them to you today, but you can contact my colleague Matthias Erickson, and we're more than happy to share the scripts and the supporting documentation with anybody. So just get in touch. We'd love to work with you, it's just kind of how we work at White. And that's all from my end. Yep?

AUDIENCE: I was going to write down the email really quickly.

FOUAD KHALIL: Oh, sure. Yeah. Absolutely. Yeah. I think we'll provide the PowerPoint, right Paolo?

PAOLO GALLI: I think so.

FOUAD KHALIL: Yeah, you'll be able to download the PowerPoint if you need it from--

PAOLO GALLI: We'll put the PowerPoint on the web page at AU.

FOUAD KHALIL: I believe we can do that. And also it's being recorded, so you can come back and play it again if you need to.

PAOLO GALLI: No, no. It's not finished.

FOUAD KHALIL: We still have a few more, and then we'll take questions also.

PAOLO GALLI: No, it's not finished. I had only a small issue with the PowerPoint. I'm sorry, just 10 minutes, 10 minutes. Oh, here is. What's next? I want to share with you some ideas about conceptual design. We are in the 2017. We are working with very complex and powerful elements, software, whatever. But actually, we are still working with the GI GO approach, garbage in, garbage out. I mean, everything depends on the quality of what I do. I'm asking to the computer to do what I want, but I am not using the computer to suggest me or to help me finding a solution.

So I want to share with you some ideas related to some scenarios of the future. I am not saying these will be, I am not saying I think this is the right way, it's just brainstorming. But I think it's important being that we are architects and we want to add value. And we want to understand how the future is being that our buildings have a long lifecycle. I think it's important having this kind of discussion. Generative design. What do we have now at the moment?

You know Project Fractal. We can create with Dynamo Studio some definitions defining geometry. We can define what are the inputs and give this dynamic definition to project Fractals, which can create the combination of values of these inputs for creating a number of scenarios based on its definition. It's a sort of generative design helping me to evaluate different scenarios based on the same shape. What could be in the future?

Do you remember the paths? The wheels, the connection I showed you before? Imagine that we have something keeping requirements, existing conditions, sketches, ideas-- I give it the set of inputs to an engine, a motor that mixes them up and gives me some configuration, some path configuration, helps me to configure a suitable path for addressing these design issues according to a number of criteria. Imagine something like that. Or imagine this one.

Have you ever used Sketchbook? No, but you know there's an interesting web based application, Google Draw I think it's called, which tries to understand the meaning of your sketch. Now, imagine that we want to drive a geometry based on its requirements. When I say a line, I'm saying that it's the set of points connecting two end points. So given these requirements, I can have the computer interpreting, understanding this stroke to this line and the same saying four points connected, parallel sides, right angles. I can have the computer understanding this, do this.

So it's possible having the computer based on requirements understanding some shapes of my design intent or my drawing intent, in this case. Just imagine in the future something helping me to sketch and to recognize the room. I do a sketch. I'm not saying the computer is designing on my side, I'm saying I do a sketch. I want the computer to use its calculation power to perform some hypothesis on understanding what is my intent. Imagine a building. Is it possible? Is this the route?

I don't know. I'm not saying this is now. I'm just brainstorming. Imagine we have some requirements. The height of the levels, the maximum volume of my building, because this is urban planning data. And I do some sketches. The system recognizes the sketches, the flavor of the sketches, and puts the height of my sketch with the height given by the requirements and starts creating a set number of possible scenarios for plan distribution, for shapes, for energy and general behavior. Is this possible? Now, no it's not. But actually, this is generated design.

This is machine learning. This is a sort of AI, artificial intelligence, using the computer for suggesting, for helping me choosing from a number of scenarios and improving it then. You remember different lenses. I was inspired by the picture I put at the very beginning, and I took this-- this is the reason why I disconnected my computer, because I needed to move this slide up. Imagine we have a special zoom. The zoom of every software we have allows us to move it this way. I mean, to make bigger or smaller on the screen a geometry.

Imagine we have a zoom and the same solution-- I'm not saying software platform, idea, or whatever-- allowing me to move on the LOD, so on the level of definition of development, from a low level that means a broader number of solutions and a big set of degrees of freedom. If you are high level of LOD, that means maybe the component. Imagine something like that. Look at this tree and imagine that by moving this wheel, the vertical axis, we can start dealing with the solution, the floor plan sketch, the area design, the area planning. We can move from the massing based on this. What's the idea?

The idea-- look at this tree. This is not a project tree, it's a life cycle tree. I'm not saying this will be the future. I'm saying this is just an idea, but let's imagine a solution helping us to involve on the same platform the whole people, the stakeholders, and all the steps on a project lifecycle. So I can have a tree with different low LOD stuff floor plans. From each of them I can create different scenarios of massing. From each of those, I can create some LOD 300, 200 elements, buildings. But inside each building, I can also define the number of components.

Then imagine that at a specific point, some requirements change and we need to take this floor plan and say, oh, instead of having a linear bar, we have an l shape. I give the system to be elaborated by the generated design element that I want this update to go downstream updating the rest. Is this possible? No, it's not. But 10 years ago, remember when someone introduced these inventors, SolidWorks, I mean the mechanical software, well there were a lot of people skeptical about that. But the tree of dependencies is a reality. Obviously, I'm imagining a system giving me some warning saying, look, once you change it so much the floor plan, the building cannot be updated.

But I'm just brainstorming. But imagine that this can involve also the last step. I mean, the components, allowing me to have information telling me that, oh, look. This margin-- in this case, the updated solution is shorter. This means that it's still working, but the size is too big for resisting, for responding to the same loads. Being that shorter, we can put a smaller margin. So imagine that this process can involve the time, so a lot broader lifecycle, different people, can we have a connection with the phases LOD and starting with the conceptual design involving even a mechanical engineer.

And you know, a mechanical engineer with construction is something strange. You know a mechanical engineer is, no? It's this strange mythological animal composed of a body of a lion and the head of a lion, but not always a lion. And this is a big issue. That's it. I wanted just to share with you these ideas to finish this. Thank you very much for your attendance. We're really happy to have had you here. Please feel free to contact us for any kind of question. If you took any picture or whatever, please send us. And before you go, I want to take a selfie with you all, because you know-- thank you. Autodesk-- make anything, and forget.

Las Vegas edition. Here it is. Smile. Thank you.

[APPLAUSE]

______
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

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

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

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

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

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

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