Two things are true about attributes in Magento (Adobe Commerce) at the same time. They look like simple fields you fill in on the admin screen, color, size, a customer phone number, and they are also rows in a database model that powers every catalog filter, every customer segment, and every storefront query you run. Treat them as just form fields and you miss why a single attribute change can slow a category page. Treat them only as database theory and you never ship the merchandising the marketing team actually asked for.
This guide covers both sides. It explains what product attributes and customer attributes are, how to create each in the admin area, how to add a custom customer attribute programmatically with a data patch, and where attribute data physically lives in the database. The focus is the work merchants and developers do together, not abstraction for its own sake.
🚀 Quick takeaway
Magento has two separate attribute families. Product attributes describe what you sell, color, size, material, and customer attributes describe who buys, phone number, tax exemption status, loyalty tier. They share the same Entity-Attribute-Value foundation but are stored, managed, and extended independently.
What are product attributes in Magento?
Product attributes are the properties that describe an item and make it distinct, color, size, material, brand, and any custom characteristic you define. They can be added, edited, and removed, and they can be grouped into attribute sets that act as templates for product types. Magento manages products, categories, and customers as entity types using the Entity-Attribute-Value (EAV) model, which stores each attribute value in its own row rather than as a fixed column.
The EAV model is what lets you add a new attribute without altering the products table schema, and it is the reason a Magento store can carry thousands of attributes across very different product types. If you want the mechanics of how EAV resolves a value at read time, the deeper explanation lives in the EAV model walkthrough.
What are customer attributes in Magento 2?
Customer attributes are properties attached to the customer entity rather than to a product, name, email, phone, tax/VAT number, date of birth, or any custom field you need to collect at registration or checkout. They use the same EAV foundation as product attributes but belong to a different entity type, so they are created, edited, and stored separately from anything in your catalog.
This is the part most product-attribute guides skip, and it matters because the work that drives loyalty programs, B2B account approval, and personalized marketing all depends on customer attributes. A tax-exemption flag, a preferred-store field, or a loyalty-tier value are all custom customer attributes you can add without touching core code.
🚀 Quick takeaway
Custom customer attributes are created under Stores > Attributes > Customer in the admin, not under the Product attributes screen. The two attribute types never share a creation path, and confusing the two is the most common reason a new field appears on the wrong form.
How do you manage product attributes in the admin area?
Product attributes are created and edited from the Product Attributes grid under the Stores menu. The admin flow lets you set the input type, decide where the attribute shows on the storefront, attach it to an attribute set, and define dropdown options, all without writing code. The steps below follow the Adobe Experience League catalog management documentation.
Setting product attribute visibility
Under the Attributes section, open Product and select the attribute you want visible on the product detail page. In the Storefront Properties tab, set “Visible on Catalog Pages on Storefront” to Yes. To surface the same attribute in listings, set “Used in Product Listing” to Yes as well.
Working with the create attribute form
On the Admin sidebar, go to Stores > Attributes > Product, then click Add New Attribute. Under Attribute Properties, enter a Default Label to identify the attribute and set the Input Type to control how data is entered.
The input type you pick decides the storefront control buyers see:
| Text Field | A single-line input field for text. |
| Text Area | A multiple-line field for paragraphs of text, such as a product description. |
| Text Editor | A full text editor at the attribute location. |
| Date | A date value in the preferred format and time zone. |
| Date and Time | A date and time value, entered manually or from a calendar. |
| Yes/No | A drop-down with pre-defined Yes and No options. |
| Dropdown | A drop-down list of values that accepts a single selection. |
| Multiple Select | A drop-down list of values that accepts multiple selections. |
| Price | Creates price fields in addition to Price, Special Price, Tier Price, and Cost. |
| Media Image | Associates an additional image with a product, such as a care label. |
| Fixed Product Tax | Defines FPT rates based on the requirements of your locale. |
| Visual Swatch | A swatch that depicts the color, texture, or pattern of a configurable product. |
| Text Swatch | A text-based option representation often used for size. |
| Page Builder | A Page Builder workspace at the attribute location for richer product content. |
To require a value on every product, set Values Required to Yes. This is the is_required flag, so any product assigned to that attribute set must carry a value or saving throws an exception. For Dropdown and Multiple Select types, open Manage Options, click Add Option, enter each value, and use Is Default to mark the default selection. Finally, enter a unique Attribute Code in lowercase with no spaces, and prefer an underscore over a hyphen in code names.
Entering the attribute label and assigning the set
Expand Manage Titles and type a Title to use as the field label, with a translated title per store view if you sell in multiple languages. Before the attribute can appear on a product, add it to that product’s attribute set, the set defines which attribute values can be set on a given product. The advanced properties then control how the attribute behaves in the catalog and when its data reaches the frontend.
🚀 Quick takeaway
The Attribute Code is permanent and lowercase with underscores. Pick it carefully, renaming an attribute code later means data migration, not a label edit, because the code is what every product value row references.
How do you create a custom customer attribute in the admin?
To add a custom customer attribute from the admin, go to Stores > Attributes > Customer and click Add New Attribute. You set the same kinds of properties as a product attribute, default label, input type, sort order, and whether a value is required, plus one customer-specific control: the forms the attribute appears on. According to the Adobe Experience League documentation, you choose which forms display the field, for example the admin customer edit form, the account registration form, and the account edit form.
That “used in forms” choice is the practical difference between a customer attribute and a product attribute. A loyalty-tier field you only want staff to see is assigned to the admin form alone, while a tax-number field a B2B buyer must submit at signup is added to the registration form. Sort order then controls where it appears relative to the other fields.
How do you create a customer attribute programmatically?
For repeatable, version-controlled changes, add a custom customer attribute with a data patch instead of clicking through the admin. A data patch is a class that implements DataPatchInterface and runs once when bin/magento setup:upgrade executes, so the same attribute is created on every environment, local, staging, and production, without anyone editing the database by hand.
Following the Webkul customer attribute guide, the patch injects CustomerSetupFactory and calls addAttribute() on the Customer entity with the attribute code, label, input type, and backend type. You then load the new attribute and set a used_in_forms array such as ['adminhtml_customer', 'customer_account_edit', 'customer_account_create'] so the field renders on the right forms, exactly the control you would otherwise pick in the admin. Running bin/magento setup:upgrade applies the patch.
Product attributes follow the same discipline. They are created programmatically with migration patches that run on setup:upgrade and on deployment, so a new color option or a new attribute set is reproduced everywhere automatically rather than being added manually on each environment and then re-synced. scandiweb is the most certified Magento team in the world, and across the projects our developers have shipped, the consistent rule is that any attribute meant to live in production gets created by patch, never by a one-off admin edit, so the schema stays identical across every environment. Teams that need hands on this can bring in Magento support to own the patch and deployment work.
🚀 Quick takeaway
Admin creation is fine for a one-off field on a single store. For anything that must exist identically across local, staging, and production, use a data patch with CustomerSetupFactory->addAttribute() and a used_in_forms array, then run setup:upgrade.
Where is attribute data stored in the database?
Attribute storage in Magento is split across an EAV set of tables, and product and customer attributes live in separate value tables. Product records live in catalog_product_entity, which holds only static attributes, system fields stored directly on the table such as sku, created_at, updated_at, has_options, and required_options. Everything else is resolved through EAV. The same split principle is part of the broader Magento architecture. Teams planning a catalog model around this storage split often bring in Magento development support to keep query performance in check as attribute counts grow.
The eav_attribute table holds the general definition of every attribute across all EAV entities, products, categories, customers, customer addresses, and anything custom. The catalog_eav_attribute table adds the extra product- and category-specific properties on top of that base definition. Product values themselves land in the typed value tables such as catalog_product_entity_varchar, catalog_product_entity_int, and catalog_product_entity_decimal, chosen by the attribute’s backend type.
Customer attribute values are stored in a parallel set of tables. Per Magento Stack Exchange, a customer attribute value lands in the matching customer_entity_* value table, for example customer_entity_varchar or customer_entity_int, according to its declared backend type. That separation is why a query against product value tables never returns customer data and vice versa, and why the two attribute types can be extended independently.
🚀 Quick takeaway
Only static system fields like sku live on the entity table. Every custom attribute value lands in a typed EAV value table chosen by backend type, which is why adding attributes never alters the core schema but does add joins to read.
Frequently asked questions
What is the difference between customer attributes and product attributes in Magento 2?
Product attributes describe items you sell and attach to the product entity, while customer attributes describe account holders and attach to the customer entity. Both use the EAV model, but they are created on different admin screens, Stores > Attributes > Product versus Customer, and their values are stored in separate database tables.
How do I create a custom customer attribute in Magento 2?
In the admin, go to Stores > Attributes > Customer and click Add New Attribute, then set the label, input type, sort order, and the forms it appears on. For version-controlled changes, create it programmatically with a data patch that calls CustomerSetupFactory addAttribute and a used_in_forms array, then run bin/magento setup:upgrade.
Can Magento attributes be created programmatically?
Yes. Both product and customer attributes can be created with patches that run during setup:upgrade. Product attributes use migration patches, and customer attributes use a data patch implementing DataPatchInterface with CustomerSetupFactory. Patches keep the attribute identical across every environment instead of being added manually on each one.
Where are customer attribute values stored in Magento 2?
Customer attribute values are stored in the EAV customer_entity_* value tables, such as customer_entity_varchar or customer_entity_int, depending on the attribute’s backend type. The attribute definition itself lives in eav_attribute, separate from product storage in catalog_eav_attribute and the catalog_product_entity_* value tables.
What is the used_in_forms array for a customer attribute?
The used_in_forms array tells Magento which forms render the customer attribute, for example adminhtml_customer for the admin customer edit form, customer_account_create for registration, and customer_account_edit for the account page. Set it in the data patch or in the admin so the field appears only where it is needed.
Why must an attribute code be lowercase with underscores?
The attribute code is the permanent reference every value row uses, so Magento requires lowercase characters and no spaces, with underscores preferred over hyphens. Renaming a code later is a data migration rather than a label change, because every stored value points back to that code.
Want attributes that power real merchandising rather than just filling form fields? Work with our certified team to extend your catalog with the product and customer data your storefront actually needs.
Share on: