- Manuals
- Brands
- Fujitsu Manuals
- Hard disk drives
- MAU3147RC SERIES
- Product/maintenance manual
-
Contents
-
Table of Contents
-
Troubleshooting
-
Bookmarks
Related Manuals for Fujitsu MAU3147RC
Summary of Contents for Fujitsu MAU3147RC
-
Page 1
C141-E222-01EN MAU3147RC MAU3073RC MAU3036RC HARD DISK DRIVES PRODUCT/MAINTENANCE MANUAL… -
Page 2
In addition, FUJITSU assumes no liability with respect to the application or use of any product or system in accordance with the descriptions or instructions contained herein; including any liability for incidental or consequential damages arising therefrom. -
Page 3
REVISION RECORD Edition Date published Revised contents February, 2005 Specification No.: C141-E222-**EN C141-E222… -
Page 4
Related Standards Product specifications and functions described in this manual comply with the following ANSI (*1) standards. Document number Title T10/1236D Rev.20 SCSI Primary Commands-2 (SPC-2) [NCITS.351:2001] T10/996D Rev. 8c SCSI-3 Block Commands (SBC) [NCITS.306:1998] T10/1157D Rev. 24 SCSI Architecture Model-2 (SAM-2) T10/1561D Rev. -
Page 5
Preface This manual describes MAU3147RC, MAU3073RC, and MAU3036RC 3.5″ type hard disk drives with an embedded Serial Attached SCSI (SAS). This manual details the specifications and functions of the above disk drive, and gives the requirements and procedures for installing it into a host computer system. -
Page 6
Preface CONVENTIONS USED IN THIS MANUAL MAU3147RC, MAU3073RC, and MAU3036RC disk drives are described as «the hard disk drives (HDD)», «the disk drive» or «the device» in this manual. Decimal number is represented normally. Hexadecimal number is represented as X’17B9′, 17B9h or 17B9H. -
Page 7
Important Alert Items Important Alert Messages The important alert messages in this manual are as follows: A hazardous situation could result in minor or moderate personal injury if the user does not perform the procedure correctly. Also, damage to the product or other property, may occur if the user does not perform the procedure correctly. -
Page 8
Data loss Save data stored on the disk drive to other media before requesting repair. Maintenance Fujitsu does not assume responsibility if data is destroyed during servicing or repair. Electreical shock 1. To avoid injury, do not touch the PCA. -
Page 9
MANUAL ORGANIZATION PRODUCT/ 1. General Description MAINTENANCE MANUAL 2. Specifications 3. Data Format (This manual) 4. Installation Requirements 5. Installation 6. Diagnostics and Maintenance 7. Error Analysis INTERFACE 1. Interface SPECIFICATIONS 2. Command Processing 3. Data Buffer Management 4. Command Specifications 5. -
Page 10
This page is intentionally left blank. -
Page 11: Table Of Contents
CONTENTS CHAPTER 1 General Description…………..1-1 Standard Features …………….1-2 Hardware Structure…………….1-5 System Configuration …………….1-6 CHAPTER 2 Specifications …………….2-1 Hardware Specifications …………..2-1 2.1.1 Model name and order number …………2-1 2.1.2 Function specifications ……………. 2-2 2.1.3 Environmental specifications …………… 2-4 2.1.4 Error rate …………………
-
Page 12
Contents 4.1.1 Dimensions ………………4-1 4.1.2 Mounting orientations …………….4-2 4.1.3 Notes on mounting …………….4-3 Power Supply Requirements…………..4-7 Connection Requirements…………..4-8 4.3.1 Connector…………………4-8 4.3.2 Interface connector …………….4-9 CHAPTER 5 Installation …………….. 5-1 Notes on Handling Drives…………..5-1 Setting………………..5-3 5.2.1 Port Address………………5-3 Mounting Drives ………………5-3 5.3.1 Mounting procedures…………….5-3 Checking Operation after Installation and Preparing the HDD for Use ………………..5-4… -
Page 13
Contents 6.2.5 Tools and test equipment …………..6-8 6.2.6 Tests………………..6-9 Operation Check…………….6-10 6.3.1 Initial seek operation check…………..6-10 6.3.2 Operation test ………………6-10 6.3.3 Diagnostic test ………………. 6-10 Troubleshooting Procedures…………… 6-11 6.4.1 Outline of troubleshooting procedures ……….6-11 6.4.2 Troubleshooting with disk drive replacement in the field …. -
Page 14
Contents Illustrations Figures Figure 1.1 Example of SAS system configuration (Dual port internal cabled environment)……..1-6 Figure 1.2 Example of SAS system configuration (Dual port internal backplane environment) ……. 1-6 Figure 3.1 Cylinder configuration…………… 3-2 Figure 3.2 Spare area in cell …………… 3-4 Figure 3.3 Alternate cylinder ………….. -
Page 15
Contents Tables Table 2.1 Model names and order numbers ……….2-1 Table 2.2 Function specifications ………….. 2-2 Table 2.3 Environmental/Power requirements ……….. 2-4 Table 3.1 Format capacity …………….. 3-8 Table 4.1 Surface temperature check point and maximum temperature ..4-5 Table 4.2 Interface connector (SAS plug) signal allocation:CN1…. -
Page 16
This page is intentionally left blank. -
Page 17: Chapter 1 General Description
CHAPTER 1 General Description Standard Features Hardware Structure System Configuration This chapter describes the feature and configuration of the hard disk drives (HDD). The HDD are high performance large capacity 3.5″ fixed disk drives with an embedded Serial Attached SCSI (SAS) controller.
-
Page 18
The HDD has two pairs of driver and receiver set (PHY) for the SAS to support dual SAS port connection. On MAU3147RC, MAU3073RC, and MAU3036RC, Primary and Secondary Ports on SAS plug connector (2 physical links plus power connections) are used for SAS port connection. -
Page 19: 1.1 Standard Features
1.1 Standard Features Cache feature After executing the READ command, the HDD reads automatically and stores (prefetches) the subsequent data blocks into the data buffer (Read-ahead caching). The high speed sequential data access can be achieved by transferring the data from the data buffer without reaccessing the disk in case the subsequent command requests the prefetched data blocks.
-
Page 20
General Description Error rate increase The drive format at factory shipment is generally 512 bytes. The recoverable Error of the drive might increase when the format would be modified from 512 bytes to the following values: 516 bytes, 520 bytes, 524 bytes, 528 bytes. The recoverable Error referred here is sense data (1-13-xx). -
Page 21: Hardware Structure
1.1 Standard Features (20) Microcode downloading The HDD implements the microcode download feature. This feature achieves easy maintainability of the HDD and function enhancing. Hardware Structure The HDD is composed of the disks, heads, and spindle motor mounted disk enclosure (DE) with actuator as well as read/write pre-amp with the printed circuit assembly (PCA) of the controller.
-
Page 22: System Configuration
General Description System Configuration For the Serial Attached SCSI, the ANSI standard defines Point-to-Point technology. Figure 1.1 and Figure 1.2 give examples of the SAS system configuration. Figure 1.1 Example of SAS system configuration (Dual port internal cabled environment) Figure 1.2 Example of SAS system configuration (Dual port internal backplane environment) Port addressing Every device connected with the SAS protocol has a unique address (SAS address).
-
Page 23: Chapter 2 Specifications
The data format can be changed by reinitializing with the user’s system. Table 2.1 Model names and order numbers Capacity Model name Order number Interface type (user area) MAU3147RC CA06646-B400 147 GB (*) MAU3073RC CA06646-B200 73.5 GB (*) MAU3036RC CA06646-B100 36.7 GB (*)
-
Page 24: Function Specifications
Specifications 2.1.2 Function specifications Table 2.2 shows the function specifications of the HDD. Table 2.2 Function specifications Specification Item MAU3147RC MAU3073RC MAU3036RC Formatted capacity/device (*1) 147 GB (*2) 73.5 GB (*2) 36.7 GB (*2) Number of disks Number of heads…
-
Page 25
2.1 Hardware Specifications (*3) The seek time is as follows: Seek Difference [4096 Cyl/div] (*4) The start time is the time from power on or start command to when the HDD is ready, and the stop time is the time for disks to completely stop from power off or stop command. This value indicates during idle mode. -
Page 26: Environmental Specifications
Specifications 2.1.3 Environmental specifications Table 2.3 lists environmental and power requirements. Table 2.3 Environmental/Power requirements Specification Item MAU3147RC MAU3073RC MAU3036RC Operating 5 to 55 °C Non-operating –40 to 70 °C Temperature Transport (within a week) –40 to 70 °C (*1) DE surface temperature at 5 to 60 °C…
-
Page 27: Error Rate
2.1 Hardware Specifications (*1) For detail condition, see Section 4.1. (*2) Vibration applied to the drive is measured at near the mounting screw hole on the frame as much as possible. (*3) At random seek write/read and default on retry setting with log sweep vibration. (*4) At power-off state after installation Vibration displacement should be less than 2.5 mm.
-
Page 28
Specifications Mean Time To Repair (MTTR) MTTR is the average time taken by a well-trained service mechanic to diagnose and repair a drive malfunction. The drive is designed for a MTTR of 30 minutes or less. Service life The service life under suitable conditions and treatment is as follows. The service life is depending on the environment temperature. -
Page 29: Chapter 3 Data Format
CHAPTER 3 Data Format Data Space Logical Data Block Addressing Defect Management This chapter explains data space definition, logical data block addressing, and defect management on the HDD. Data Space The HDD manages the entire data storage area divided into the following three data spaces. •…
-
Page 30: Figure 3.1 Cylinder Configuration
Data Format Note: Spare sectors on the last track in each cylinder are not necessarily placed at the end of the track because of a track skew or a cylinder skew. (Details are explained in Subsection 3.1.3) Figure 3.1 Cylinder configuration Apart from the above logical configuration, the HDD intends to increase the storage capacity by dividing all cylinders into several zones and changing a recording density of each zone.
-
Page 31
3.1 Data Space User space The user space is a storage area for user data. The data format on the user space (the length of data block and the number of data blocks) can be specified with the MODE SELECT or MODE SELECT EXTENDED command. -
Page 32: Alternate Spare Area
Data Format 3.1.2 Alternate spare area The alternate spare area consists of the last track of each cell in the user space and an alternate cylinder allocated to the last cylinder of each zone. The spare area in each cell is placed at the end of the last track as shown in Figure 3.2. These spare sectors are located in the end of the track logically, not necessarily located at the end physically because of track skew or cylinder skew.
-
Page 33: Track Format
3.1 Data Space 3.1.3 Track format Physical sector allocation Figure 3.4 shows the allocation of the physical sectors in a track. The length in bytes of each physical sector and the number of sectors per track vary depending on the logical data block length. The unused area (G4) exists at the end of the track in formats with most logical data block lengths.
-
Page 34: Sector Format
Data Format Track skew Head Track skew Head skew Head Leading logical sector in head p+1 Figure 3.5 Track skew/head skew The number of physical sectors (track skew factor and head skew factor) corresponding to the skew time varies depending on the logical data block length because the track skew and the head skew are managed for individual sectors.
-
Page 35
3.1 Data Space Each sector on the track consists of the following fields: Gaps (G1, G2, G3) No pattern is written on the gap field. PLO Sync In this field, pattern X’00’ is written. Sync Mark (SM1, SM2) In this field, special pattern is written. This special pattern indicates the beginning of the data field. Data field (DATA1-DATA4) User data is stored in the data field of the sector. -
Page 36: Format Capacity
READ CAPACITY, MODE SENSE, or MODE SENSE EXTENDED command after initializing the disk medium. Table 3.1 Format capacity Model Data block length User blocks Format capacity (GB) MAU3147RC 287,277,984 147.0 (*) MAU3073RC 143,638,992 73.5 (*) MAU3036RC 71,819,496 36.7 (*)
-
Page 37: 3.2 Logical Data Block Addressing
3.2 Logical Data Block Addressing Block address of user space The logical data block address number is consecutively assigned to all of the data blocks in the user space starting with 0 to the first data block. The HDD treats sector 0, track 0, cylinder 0 as the first logical data block. The data block is allocated in ascending order of addresses in the following sequence (refer to Figure 3.5): 1) Logical data blocks are assigned in ascending order of sector number in the same track.
-
Page 38: Defect Management
Data Format Defect Management 3.3.1 Defect list Information of the defect location on the disk is managed by the defect list. The following are defect lists which the HDD manages. • P list (Primary defect list): This list consists of defect location information available at the disk drive shipment and is recorded in a system space.
-
Page 39: Figure 3.7 Alternate Block Allocation By Format Unit Command
3.3 Defect Management Alternate block allocation during FORMAT UNIT command execution When the FORMAT UNIT command is specified, the allocation of the alternate block to those defective sectors included in the specified lists (P, G, or D) is continued until all spare sectors in the same cell are used up.
-
Page 40: Figure 3.8 Alternate Block Allocation By Reassign Blocks
Data Format If above errors are detected during FORMAT UNIT command, the HDD allocates the alternate block(s) to the defective data blocks. Reassign procedure itself is the same as one in REASSIGN BLOCKS command. Certification is permitted when DCRT flag is cleared (DCRT flag=0) in FORMAT UNIT command.
-
Page 41
3.3 Defect Management Automatic alternate block allocation • Automatic alternate block allocation at read operation If the ARRE flag in the MODE SELECT parameter permits the automatic alternate block allocation, the HDD automatically executes the alternate block allocation and data duplication on the defective data block detected during the READ or READ EXTENDED command. -
Page 42
Data Format Type 2 (Reassignment of write fail sector) 1) Commands to be applied WRITE WRITE EXTENDED FORMAT UNIT WRITE at executing WRITE AND VERIFY 2) Application requirements / processing When WRITE/WRITE EXTENDED command detects any Servo error (e.g. Write offtrack error) and cannot be recovered within pre-determined retry number (specified in Mode Parameter). -
Page 43: Chapter 4 Installation Requirements
CHAPTER 4 Installation Requirements Mounting Requirements Power Supply Requirements Connection Requirements This chapter describes the environmental, mounting, power supply, and connection requirements. Mounting Requirements 4.1.1 Dimensions Figures 4.1 show the dimensions of the HDD and the location of the mounting screw holes. [Units: mm] Figure 4.1 Dimensions…
-
Page 44
Installation Requirements 4.1.2 Mounting orientations The permissible orientations of the HDD are shown in Figure 4.3, and the tolerance of the angle is ±5° from the horizontal plane. (a) Horizontal –1 (b) Horizontal –2 (c) Vertical –1 (d) Vertical –2 (e) Upright mounting –1 (f) Upright mounting –2 Direction of gravity… -
Page 45: Notes On Mounting
4.1 Mounting Requirements 4.1.3 Notes on mounting Damage Never remove any labels from the drive or deface them in any way. Mounting frame structure Special attention must be given to mount the HDD as follows. Use the frame with an embossed structure, or the like. Mount the HDD with making a gap of 2.5 mm or more between the HDD and the frame of the system.
-
Page 46
Installation Requirements Limitation of side-mounting Mount the HDD using the 4 screw holes at the both ends on the both sides as shown in Figure 4.4. Do not use the center hole by itself. In case of using the center hole, it must be used in combination with 2 holes on both ends. (Total 6 screws for 6 holes enclosed) Holes for mounting screw… -
Page 47: Figure 4.5 Surface Temperature Measurement Points
4.3 Connection Requirements Environmental temperature Temperature condition at installed in a cabinet is indicated with ambient temperature measured 30 mm from the disk drive. At designing the system cabinet, consider following points. • Make a suitable air flow so that the DE surface temperature never exceed 60°C. •…
-
Page 48
Installation Requirements Service clearance area The service clearance area, or the sides which must allow access to the HDD for installation or maintenance, is shown in Figure 4.6. [Surface X] • Holes for mounting screw [Surface Y] (Both side) • Interface connection [Surface Z] •… -
Page 49: Power Supply Requirements
Subsection 2.1.3. (For other requirements, see Items (4) and (5) below.) Current waveform (reference) Figure 4.7 shows the spin-up current waveform of +12V DC. MAU3147RC MAU3073RC MAU3036RC Time (2 sec/div) Time (2 sec/div) Time (2 sec/div) Figure 4.7…
-
Page 50: Connection Requirements
Installation Requirements Noise filter To eliminate AC line noise, a noise filter should be installed at the AC input terminal on the HDD power supply unit. The specification of this noise filter is as follows: • Attenuation: 40 dB or more at 10 MHz •…
-
Page 51: Interface Connector
4.3 Connection Requirements 4.3.2 Interface connector Figure 4.10 shows the SAS type interface connector (SAS plug) overview. Table 4.2 lists the signal allocation of the SAS plug on the HDD. Figure 4.10 SAS plug connector overview C141-E222…
-
Page 52: Table 4.2 Interface Connector (Sas Plug) Signal Allocation:cn1
Installation Requirements Table 4.2 Interface connector (SAS plug) signal allocation:CN1 Pin No. Signal Description GND for SAS Primary Port SAS Primary Port Receive (positive) signal SAS Primary Port Receive (negative) signal GND for SAS Primary Port SAS Primary Port Transmit (negative) signal SAS Primary Port Transmit (positive) signal GND for SAS Primary Port GND for SAS Secondary Port…
-
Page 53: Chapter 5 Installation
CHAPTER 5 Installation Notes on Handling Drives Setting Mounting Drives Checking Operation after Installation and Preparing the HDD for Use Dismounting Drives Spare Disk Drive This chapter describes the notes on handling drives, setting, mounting drives, confirming drive operations after installation and preparation for use, and dismounting drives. Notes on Handling Drives The items listed in the specifications in Table 2.3 must be strictly observed.
-
Page 54
Installation Unpackaging a) Use a flat work area. Check that the «This Side Up» sign side is up. Handle the package on soft material such as a rubber mat, not on hard material such as a desk. b) Be careful not to give excess pressure to the internal unit when removing cushions. c) Be careful not to give excess pressure to the PCA and interface connector when removing the drive from the Fcell. -
Page 55: 5.2 Setting
5.2 Setting Setting 5.2.1 Port Address Every device that uses the SAS interface has a unique SAS address, and commands use an SAS address to identify each device for I/O operations. Every HDD is assigned a unique SAS address before shipment from the factory, so setting of an address is not required before the HDD is used. Mounting Drives 5.3.1 Mounting procedures…
-
Page 56: Checking Operation After Installation And Preparing The Hdd For Use
Installation Checking Operation after Installation and Preparing the HDD for Use 5.4.1 Checking initial operation The procedure for verifying operation after power-on is explained below. Initial diagnosis at the time of power-on: a) When the HDD is turned on, the Active LED blinks and the HDD performs the initial self- diagnosis (controller hardware diagnosis).
-
Page 57: Formatting
5.4 Checking Operation after Installation and Preparing the HDD for Use Checking at abnormal end a) When sense data can be obtained with the REQUEST SENSE command, analyze the sense data and retry recovery for a recoverable error. Refer to Chapter 5 “Sense Data and Error Recovery Method”…
-
Page 58
Installation FORMAT UNIT command Initialize entire recording surface of the disk with the FORMAT UNIT command. The FORMAT UNIT command initializes entire surface of the disk using the P lists, verifies data blocks after initialization, and allocates an alternate block for a defect block detected with verification. With initialization, the value «00»… -
Page 59: Setting Parameters
5.4 Checking Operation after Installation and Preparing the HDD for Use 5.4.3 Setting parameters The user can specify the optimal operation mode for the user system environments by setting the following parameters with the MODE SELECT or MODE SELECT EXTENDED command: •…
-
Page 60
Installation Error recovery parameters The following parameters are used to control operations such as HDD internal error recovery: a. Read/write error recovery parameters (page code = 1) Parameter Default value • AWRE: Automatic alternate block allocation at Write 1 (enabled) operation •… -
Page 61
5.4 Checking Operation after Installation and Preparing the HDD for Use Caching parameters The following parameters are used to optimize HDD Read-Ahead caching operations under the system environments. Refer to Chapter 3 “Data Buffer Management” of the Serial Attached SCSI Interface Specifications for further details. -
Page 62: Dismounting Drives
Installation Dismounting Drives Since the method and procedure for dismounting the disk drive for replacement of the drive, etc. depends on the locker structure of the system, etc., the work procedure must be determined in consideration of the requirements specific to the system. This section describes the general procedure and notes on dismounting the drive.
-
Page 63: Chapter 6 Diagnostics And Maintenance
CHAPTER 6 Diagnostics and Maintenance Diagnostics Maintenance Information Operation Check Troubleshooting Procedures This chapter describes diagnostics and maintenance information. Diagnostics 6.1.1 Self-diagnostics The HDD has the following self-diagnostic function. This function checks the basic operations of the HDD. • Initial self-diagnostics •…
-
Page 64
Diagnostics and Maintenance Brief test contents of self-diagnostics are as follows. a. Hardware function test This test checks the basic operation of the controller section, and contains following test. • RAM (microcode is stored) • Peripheral circuits of microprocessor (MPU) •… -
Page 65
6.1 Diagnostics Online self-diagnostics (SEND DIAGNOSTIC command) The INIT can make the HDD execute self-diagnostics by issuing the SEND DIAGNOSTIC command. The INIT specifies the execution of self-diagnostics by setting 1 for the SelfTest bit on the CDB in the SEND DIAGNOSTIC command and specifies the test contents with the UnitOfl bit. -
Page 66: Test Programs
Diagnostics and Maintenance When an error is detected in the hardware function test, the HDD posts the CHECK CONDITION status for all I/O operation request except the REQUEST SENSE command. The error status is not cleared even if the error information (sense data) is read. Only when the power is turned off or re-turned on, the status can be cleared.
-
Page 67: 6.2 Maintenance Information
Data loss Save data stored on the disk drive to other media before requesting repair. Fujitsu does not assume responsibility if data is destroyed during servicing or repair. See Section 5.1 for notes on packing and handling when returning the disk drive.
-
Page 68: Maintenance Requirements
The PCA cannot be replaced in the field. The DE cannot be replaced in the field. Service system and repairs Fujitsu has the service system and repair facility for the disk drive. Contact Fujitsu representative to submit information for replacing or repairing the disk drive. Generally, the following…
-
Page 69: Maintenance Levels
Replacement is usually done by the user, retail dealer, distributor, or OEM engineer. Factory maintenance (parts replacement) • This replacement can only be done by Fujitsu. • Replacement includes maintenance training and OEM engineer support. OEM engineers usually support retail dealers and distributors.
-
Page 70: Tools And Test Equipment
(see Figure 6.2). When the revision number is changed after the drive is shipped from the factory, Fujitsu issues «Engineering Change Request/Notice» in which the new revision number is indicated. When the user changes the revision number, the user should update the revision label as described in item (2) after applying the modification.
-
Page 71: Tests
6.2 Maintenance Information 6.2.6 Tests This disk drive can be tested in the following ways: • Initial seek operation check (See Subsection 6.3.1) • Operation test (See Subsection 6.3.2) • Diagnostic test (See Subsection 6.3.3) Figure 6.3 shows the flow of these tests. Start Start self-test by turning the power on…
-
Page 72: Operation Check
Diagnostics and Maintenance Operation Check 6.3.1 Initial seek operation check If an error is detected during initialization by the initial seek operation check routine at power-on, the spindle motor of the disk drive stops, and then the disk drive becomes unusable. For an explanation of the operation check before the initial seek, refer to the Section 5.4.
-
Page 73: Troubleshooting Procedures
6.4 Troubleshooting Procedures Troubleshooting Procedures 6.4.1 Outline of troubleshooting procedures This section explains the troubleshooting procedures for disk drive errors. Depending on the maintenance level, analyze the error to detect a possibly faulty part (disk drive, or disk drive part). Full-scale troubleshooting is usually required if the error cause is not known.
-
Page 74: Table 6.2 System-Level Field Troubleshooting
Diagnostics and Maintenance Table 6.2 System-level field troubleshooting Item Recommended work DC power level Check that the DC voltage is within the specified range (±5%). For +5V DC, measure the voltage between pin P8 (+5V) of the interface connector and the nearest PCA mounting screw (GND) from the interface connector, and confirm the value is from 4.75 to 5.25 VDC.
-
Page 75: Troubleshooting At The Repair Site
6.4 Troubleshooting Procedures 6.4.3 Troubleshooting at the repair site For maintenance at this level, we recommend additional testing of the disk drive and signal checking. The sense data posted from the HDD helps with troubleshooting. This sense data makes the error type clear (functional, mechanical, or electrical error).
-
Page 76: Troubleshooting With Parts Replacement In The Factory
Diagnostics and Maintenance 6.4.4 Troubleshooting with parts replacement in the factory This manual does not cover troubleshooting at the factory level. 6.4.5 Finding possibly faulty parts Finding possibly faulty parts in the field was explained in Subsection 6.4.2. This manual does not cover finding possibly faulty parts at the factory level.
-
Page 77: Chapter 7 Error Analysis
CHAPTER 7 Error Analysis Error Analysis Information Collection Sense Data Analysis This chapter explains in detail how sense data collected from a disk drive is used for troubleshooting. Sense data reflects an error in the disk drive, and helps with troubleshooting. A sense key, additional sense code, and additional sense code qualifier, taken from various sense data are repeated.
-
Page 78: Figure 7.1 Format Of Extended Sense Data
Error Analysis Bit 7 Byte 0 Valid X‘70’ or X‘71’ (error code) X‘00’ Sense key [MSB] Information [LSB] X‘28’ (additional sense data length) [MSB] Basic information Command-specific information [LSB] Additional sense code Additional sense code qualifier X‘00’ SKSV Sense key-specific information Port CDB operation code Additional…
-
Page 79: Sense Data Analysis
7.2 Sense Data Analysis Sense Data Analysis 7.2.1 Error information indicated with sense data Subsection 7.2.2 onwards explain troubleshooting using sense data. For details of the following sense data, refer to Chapter 5 “Sense Data Error Recovery Methods” of the Interface Specifications. Table 7.1 lists the definition of sense data.
-
Page 80: Sense Data (3-0C-03), (4-40-Xx), And (4-C4-Xx)
Error Analysis 7.2.2 Sense data (3-0C-03), (4-40-xx), and (4-C4-xx) Sense data (3-0C-03), (4-40-xx), and (4-C4-xx) indicate one of the following: • A target sector could not be detected using the sector counter. • A seek process overran the specified time. •…
-
Page 81: Glossary
Glossary Additional Sense Code This is a 1-byte code displayed in the sense data and is information which specifies the type of error that was detected. Common Command Set This is the standard form of SCSI logical specifications stipulated by the operations subcommittee of the American National Standards Institute (ANSI) which stipulates functions which a direct access device (magnetic disk, etc.) should support.
-
Page 82
Glossary Target (TARG) This is the SAS device that executes the input/output operations initiated by the initiator (INIT). In this manual, target is abbreviated «TARG.» GL-2 C141-E222… -
Page 83
Acronyms and Abbreviations Disable Transfer on Error Alternating Current ACKnowledge Error Correction Code Asynchoronous Event Notification Enable Early Recovery ALTernated (block) EVPD Enable Vital Product Data ARRE Automatic Read Reallocation Enabled ASCII American Standard Code for Information Interchange ASiGned block Frame Ground ATTeNtion FIFO… -
Page 84
Acronyms and Abbreviations Magnetro Resistive Transfer Block Multiple Select Tracks Per Inch MeSsaGe TeRMinator Original Equipment Manufacturer UnitOfl Unit Offline P list Primary defect list Voice Coil Motor Parts/Number Vital Product Data PBdata Physical Block data Vendor Unique PC board Printed Circuit board Printed Circuit Assembly Post ERror Page Format… -
Page 85
Index data security at power failure ……. 2-6 data space ………… 3-1 defect list …………3-10 AC noise filter ……….4-8 defect management ……..3-10 actuator…………1-5 defective block slipping ……. 1-4 allowable input voltage and current ….4-7 definition of sense data……… 7-3 alternate area ………. -
Page 86
Index general note……….5-1 note on handling drive ……..5-1 note on mounting ……….4-3 hardware function test ……..6-2 hardware specification……..2-1 online self-diagnostic ……..6-3 hardware structure ……..1-5 operation check………..6-10 head …………. 1-5 operation test ……….6-10 high speed positioning……..1-4 outline of troubleshooting procedure…6-11 high-speed data transfer…….. -
Page 87
Index 5-2x-xx ……….7-4 B-44-xx ……….7-4 test …………..6-9 B-47-xx ……….7-4 test flowchart ……….6-9 B-4B-xx……….7-4 test program ……….6-4 B-4E-00 ……….7-4 tool and test equipment …….. 6-8 E-1D-00……….7-4 track format ……….3-5 sense data analysis……..7-3 track skew and head skew …… -
Page 88
This page is intentionally left blank. -
Page 89
List any errors or suggestions for improvement. Page Line Contents Please send this form to the address below. We will use your comments in planning future editions. Address: Fujitsu Learning Media Limited 37-10 Nishikamata 7-chome Oota-ku Tokyo 144-0051 JAPAN Fax: 81-3-3730-3702… -
Page 90
This page is intentionally left blank.
MAU, WAU и DAU — метрики мобильных приложений, которые позволяют анализировать активность пользователей приложения и своевременно реагировать на их поведение.
Если метрики посещаемости растут, значит, приложение набирает популярность, людям нравится им пользоваться и они более расположены платить за дополнительные опции — прибыль увеличивается. Если число активных пользователей падает — у проекта проблемы и нужно искать причину потери интереса к нему.
Активные пользователи (Active Users) — это те, кто заходил в приложение хотя бы один раз за конкретный отрезок времени. Обычно отслеживают дневную (DAU), недельную (WAU) и месячную (MAU) активность.
Что это за метрики и зачем их отслеживать
DAU (Daily Active Users) — это количество уникальных пользователей за сутки. Стабильно высокие показатели DAU говорят о том, что ваш продукт интересен пользователям.
Пример: Допустим, игру установили 10 человек. На следующий день зашли в неё только четверо, значит, DAU метрика этого дня будет равна 4, даже если кто-то из них заходил поиграть несколько раз за день. Если на следующий день никто из 10 пользователей не зайдет в игру, то метрика DAU будет равна 0.
DAU целесообразно отслеживать на продуктах, которыми люди пользуются каждый день: игры, календари, электронная почта.
WAU (Weekly Active Users) — это количество пользователей за неделю. Неделя — это не обязательно период с понедельника по воскресенье, это может быть, например, период со среды по вторник. То есть любые 7 дней подряд.
Пример: Возьмём тех же 10 пользователей игры из прошлого примера. Если за неделю каждый из них зашёл в приложение хотя бы по одному разу, то метрика WAU будет равна 10. Если семеро заходили в игру по несколько раз за эту неделю, а трое не заходили вовсе — WAU будет равна 7.
WAU имеет смысл отслеживать на продуктах, которые используют часто: форумах, мессенджерах или, например, в Pregnancy-календарях (календари для беременных), где еженедельно публикуется новая полезная информация.
MAU (Monthly Active Users) — это количество уникальных пользователей за месяц. Считается MAU метрика аналогично WAU.
MAU стоит отслеживать в продуктах, которые используются несколько раз в месяц, например, в приложениях для ведения бухгалтерского учета.
Можно отслеживать сразу все три метрики, просто каждая будет отражать свой аспект поведения пользователей. Например, DAU покажет моментальную реакцию людей на запуск рекламной компании — если цифры быстро растут, значит, реклама эффективна. В то время как метрики MAU и WAU больше говорят о стабильности спроса на приложение.
WAU, MAU и DAU всегда будут отличаться, потому что всегда будут пользователи, которые запускают приложение один раз в неделю, несколько раз в день, пару раз в месяц, раз в полгода и так далее.
Из-за того, что число активных пользователей не может быть стабильным, сложно понять, за счёт чего происходит динамика. Чтобы было легче разобраться, сегментируйте Active Users под ваши задачи.
Пример: допустим, у вас приложение для занятий фитнесом и вам нужно, чтобы после регистрации пользователь заполнил анкету. Так вы получите входные данные о человеке, на основании которых сможете рассчитать ему план питания и тренировок. Но метрики активности не отражают количества активных пользователей, которые выполнили нужное действие. Если сегментировать людей по кастомному событию (заполнение анкеты), то вы увидите, какой процент людей из общего числа оставили нужные данные о себе. Если таких мало, возможно, вам нужно поработать над коммуникацией, чтобы понятнее доносить ценность действия до пользователей.
Примеры сегментации активных пользователей:
- По платежам (платили/не платили, платили один раз/платили повторно).
- По времени посещений после инсталляции приложения (1 день/2–7 дней/8–14 дней/15–30 дней и т.д.).
- По регулярности посещений (ежедневно/4–6 раз в неделю/1–2 раза в неделю/1 раз в месяц).
- По странам.
- По устройствам (планшет/десктоп/смартфон).
- По событию (выполнил действие/не выполнил действие).
Сегментация позволяет увидеть причинно-следственные связи. Например, растущие цифры от покупки платного контента будут говорить об удачном запуске акции на этот контент. Если покупать платный контент стали меньше, возможно, он перестал удовлетворять требования аудитории или людей не устраивает цена.
Коэффициент «липучести» и другие показатели активности пользователей
На основании метрик DAU, WAU и MAU можно высчитать степень заинтересованности клиентов в продукте (Stickness).
Sticky Factor, или Stickness (степень вовлечённости, коэффициент «липучести») — показатель лояльности аудитории к приложению. Показывает, как часто клиенты возвращаются в приложение в течение недели или месяца.
Высокий процент «липучести» означает, что люди часто пользуются вашим приложением. Чем выше лояльность, тем охотнее пользователи рекомендуют приложение друзьям и знакомым, тем больше прирост активной аудитории.
Если Stickiness падает, это говорит о том, что приложение перестало закрывать потребности пользователей.
Чтобы узнать, в какое конкретно время юзеры наиболее активно пользуются приложением, рассчитывают показатели PCCU и ACU.
PCCU (Peak Concurrent User), она же PCU — максимальное число людей, единовременно находящихся в приложении. Измеряется за час, месяц или год.
ACU (Average Concurrent User) — среднее число посетителей за конкретный период времени.
Эти метрики пригодятся, например, когда нужно определить лучшее время для запуска рекламной кампании.
Метрики активности и коэффициент вовлечённости позволяют рассчитать финансовые показатели продукта.
Расчёт основных финансовых показателей приложения
Важнейшие метрики для оценки эффективности приложения: ARPU, ARPPU и LTV.
ARPU (Average Revenue Per User) — средняя прибыль с одного клиента за конкретный период. Индекс показывает доходность продукта в целом. Чем выше ARPU, тем больше доход от приложения и тем интереснее оно для инвесторов.
Рассчитать ARPU можно двумя способами:
- Чистый доход за выбранный период* (Revenue) разделить на Active Users за этот же период (DAU/WAU/MAU).
*чистый доход — это совокупный доход за минусом комиссии магазина приложений. - Средний доход от одного платящего пользователя (ARPPU) умножить на долю платящих из всей аудитории (Paying Share).
Пример:
Если приложение за месяц принесло условные $1000 дохода, а мы знаем, что за этот период им воспользовались 200 человек, то получаем:
ARPU = 1000 / 200 = $5
То есть каждый клиент за этот месяц в среднем принес $5 дохода.
Нельзя сказать, какой именно ARPU плохой или хороший. Этот показатель отслеживают в динамике. Например, если ежемесячная средняя прибыль падает, значит, нужно принимать меры: пересмотреть ценовую политику, сделать продукт более ценным для клиентов, привлекать больше новых пользователей.
ARPPU (Average Revenue Per Paying User) — средняя прибыль с одного платящего клиента за конкретный период. Индекс показывает прибыльность платных опций и отражает реакцию платящих пользователей на обновления, добавление услуг, изменение цен и другие ваши действия.
Для расчёта ARPPU нужно доход за выбранный период (Revenue) разделить на число платящих пользователей (Paying Users).
LTV (Lifetime Value), он же CLV (Customer Lifetime Value) — среднее количество денег от одного пользователя за всё время использования приложения. Метрика позволяет оценить эффективность рекламных каналов, оптимизировать расходы на привлечение пользователей, планировать доходы.
Для расчёта LTV чаще всего используют одну из двух формул:
- Доход от пользователя (ARPU) умножить на показатель средней продолжительности использования (Lifetime).
- Перемножить средний чек (AOV), частоту повторных покупок (RPR) и Lifetime.
Если LTV меньше, чем CPI (стоимость установки приложения), вы несете убытки. Для увеличения LTV можно уменьшить затраты на привлечение пользователей, увеличить цену платного контента, повысить ценность приложения для клиентов.
Конечная цель разработки любого приложения — получение прибыли. А метрики DAU, WAU и MAU — это маркеры, которые показывают эффективность и потенциал вашего проекта. Не забывайте отслеживать метрики активности мобильных приложений. Это позволит держать руку на пульсе и улучшать ваш продукт.
Главные мысли
Monthly Active Users или сокращенно MAU — одна из наиболее важных продуктовых метрик. Она показывает число уникальных пользователей в месяц. Тех, кто хотя бы один раз за месяц был активен, заходил в продукт и что–то в нем делал.
Миша Ряженка
Founder, Executive Partner
Что такое Monthly Active Users?
Monthly Active Users(mau) — это одна из метрик мобильных приложений. Она показывает число уникальных пользователей в месяц. Тех, кто хотя бы раз за месяц был активен, заходил в продукт и что–то в нем делал.
Миша Ряженка
Founder, Executive Partner
Зачем измерять Monthly Active Users?
Высокий показатель MAU говорит о том, что у продукта сформирована постоянная активная аудитория. Но если приложение скачали сотни тысяч человек, а его MAU меньше тысячи пользователей, значит оно никому не нужно.
Миша Ряженка
Founder, Executive Partner
DAU и MAU
Близкий товарищ метрики Monthly Active Users — метрика Daily Active Users (она же DAU). Показывает число уникальных пользователей приложения в день. Тех, кто каждый день (или регулярно) пользуется продуктом.
Миша Ряженка
Founder, Executive Partner
Monthly Active Users
Monthly Active Users или сокращенно mau — это одна из метрик мобильных приложений. Она показывает число уникальных пользователей в месяц. Тех, кто хотя бы раз за месяц был активен, заходил в продукт и что–то в нем делал.
Высокий показатель MAU говорит о том, что у продукта сформирована постоянная активная аудитория. Но если приложение скачали сотни тысяч человек, а его Monthly Active Users не дотягивает даже до тысячи пользователей, значит оно никому не нужно. А такой ажиотаж по скачиваниям могли вызвать, например, публикации с упоминанием продукта на тематических сайтах.
Без требований к образованию
Работа в IT — с нуля, за 10 месяцев
-
Персональная работа 1–на–1, по «спринтам»
Вы будете учиться с личным наставником, а не в группе
-
Индивидуальная адаптация программы
В зависимости от уровня вашей подготовки и цели
-
Обучение кросс–компетенциям профессий
Со всех наших 4 профессиональных направлений
Миша Ряженка
Founder, Executive Partner
Зачем измерять Monthly Active Users? (v2)
- Чтобы понимать, насколько активны и вовлечены пользователи в ваше приложение. Вовремя увидеть, если что–то пошло не так.
- MAU — это метрика активности, она показывает, сколько клиентов скачали и используют приложение. Позволяет лучше понять целевую аудиторию продукта, кто на самом деле его использует. А еще помогает проанализировать, какие у этой аудитории запросы.
- Все эти подсказки пригодятся вашим маркетологам, чтобы лучше настраивать рекламу, готовить скидки и акции.
Если продукт работает по модели платной подписки, то на первом месте — чтобы пользователи платили, а не заходили в продукт. Но в тоже время, если человек заплатил, но не заходит в приложение, то он не получает от него никакой ценности. Значит, когда подписка закончится, он уйдет. Поэтому важно опираться на метрику MAU в общем контексте.
Миша Ряженка
Founder, Executive Partner
DAU и MAU (v2)
Близкий товарищ метрики Monthly Active Users — метрика Daily Active Users (она же DAU). Показывает число уникальных пользователей приложения в день. Тех, кто каждый день (или регулярно) пользуется продуктом.
Допустим, ваше приложение установил себе один миллион пользователей. Но пользоваться им каждый день стали всего 1000 человек. Это те самые DAU. А вот сам по себе результат, честно говоря, так себе. Есть над чем работать.
Если все ваши пользователи каждый день будут заходить в приложение и так весь месяц, то метрики Daily Active Users и Monthly Active Users будут равны. Правда, в реальной жизни такого не происходит, увы.
Показатели MAU и DAU системы аналитики измеряют автоматически. Специалист интерпретирует и оценивает эти показатели — нормально или нет, что исправлять. Так, если вернуться к прошлому примеру, то если бы установок было 10 тысяч, а фанатами продукта стала та же 1000 человек, то этот результат был бы очень даже хорош. И вам удалось создать отличный продукт.
Миша Ряженка
Founder, Executive Partner
Monthly Active Users и «липкость»
MAU и DAU помогают рассчитать коэффициент «липкости» или лояльности пользователей к вашему продукту. Это метрика Stickiness. Она показывает насколько часто пользователи возвращаются в приложение.
Чтобы рассчитать «липкость», нужно рассчитать процентное соотношение ежедневных активных пользователей к ежемесячным. Например, у нас 3000 пользователей DAU и 5000 пользователей MAU. Считаем процентное соотношение и получаем 60% — Stickiness.
Понятно, что чем этот процент выше, тем лучше. Значит, люди часто пользуются вашим продуктом. Вполне нормально и даже здорово, когда «липкость» постепенно растет. Приходят новые пользователи, продукт им нравится, они начинают рекомендовать его другим.
А вот если коэффициент пошел вниз, значит что–то в нем перестало людей устраивать. Может, появился более удобный конкурент? Или продукт перестал решать проблему так, как нужно пользователям? Перестал соответствовать их ожиданиям? Со всем этим предстоит разбираться продуктовой команде и аналитику.
Миша Ряженка
Founder, Executive Partner
Метрика LMAU
Если поток новых пользователей в приложении нестабилен, как говорится то густо, то пусто, то используют метрики лояльности — LDAU и LMAU.
Так, LDAU позволяет рассчитать количество лояльных уникальных пользователей, которые запускали приложение в конкретный день. К лояльным относят тех, кто запустил приложение минимум один раз, спустя сутки после первого визита.
Чем меньше разница между показателями LDAU и DAU, LMAU и MAU, тем лучше. Значит, лояльных больше, чем тех, кто зашел один раз и не вернулся на следующий день.
Миша Ряженка
Founder, Executive Partner
Monthly Active Users в геймдеве
В мобильных играх метрика Monthly Active Users измеряет количество уникальных игроков, которые возвращались к игре хотя бы раз за месяц.
- Чтобы проанализировать MAU нужно разделить пользователей на группы по дням недели, в который они скачали игру.
- Если постоянно отслеживать метрику, то можно запускать рекламные кампании именно в те дни, когда активных пользователей приходило больше всего.
- Для игр хорошим считается уровень DAU/MAU в 20-30% от общего числа пользователей. Для сравнения, в мессенджерах этот показатель считают удачным, если он в районе 50%.
Миша Ряженка
Founder, Executive Partner
Кейс по увеличению метрики Monthly Active Users
Соревновательная платформа по киберспорту fragem.gg была запущена 1,5 года назад. Аудитория проекта — молодежь до 30 лет. Всего порядка 20 миллионов пользователей в СНГ.
В проекте начали тестировать маркетинговые гипотезы. Заметили, что стоимость активного пользователя выходит дороже, чем рассчитывали в самом начале. Стали разбираться, в чем причина.
Чтобы начать игру, пользователям нужно было зарегистрироваться на платформе. Затем они попадали на страницу с рейтингом игроков и команд. Там тоже нужно было пройти регистрацию. Но как показал Вебвизор в Яндекс.метрике, сразу после первой регистрации пользователи жали на кнопку «Играть». Ничего не происходило и они закрывали сайт.
Разработчики сделали видеогайд, добавили выспывающее окно с предупреждением, что нужно зарегистрироваться еще и в рейтинге. После этого действия, конверсия в активных игроков выросла на 15%.
Команда решила, что можно пойти еще дальше, и сделала автоматическую регистрацию в рейтинге. Чтобы пользователи сразу могли начать игру, без дополнительных настроек.
Такое простое действие позволило увеличить метрику Monthly Active Users в 2,2 раза. При этом бюджет на маркетинг остался прежним.
Миша Ряженка
Founder, Executive Partner
Риски в использовании метрик DAU и MAU в играх
Метрики DAU и MAU изменчивы. Но при этом не объясняют, из–за чего произошел рост пользователей.
- Это был результат PR, когда о приложении упомянули в профильных СМИ?
- Или это успешная маркетинговая кампания, которая привлекла много новых пользователей?
- Или, напротив, кампания по удержанию «старых» пользователей?
Факторы разные, но почти во всех случаях нельзя рассчитывать на устойчивый и долгосрочный результат.
Полагаться всегда только на метрики DAU и MAU нельзя, бывают случаи, когда они отстают и не показывают реальную картину. Например, вы создали мобильную игру. Особенно пристально следите за метриками ежедневной и ежемесячной активности и удержания пользователей. Вы создали новую функцию. Получили отзывы, что из–за нее стало сложнее проходить уровни. Но решили, что надо провести A / B тест. Он не показал, что новая функция как–то негативно повлияла на приложение. Все вроде бы хорошо, и вы запускаете новую функцию на всех пользователей.
Через какое–то время вы замечаете, что все меньше людей стало доходить до сложных уровней. Однако показатели DAU и MAU держатся на прежнем уровне. Что же происходит?
Дело в том, что пользователям стало сложнее играть в вашу игру, но они все еще пытаются. Однако вскоре им это надоест, и вы увидите, как это повлияет на DAU и MAU. Спойлер: не в лучшую сторону. Метрики пойдут вниз, это означает, что люди стали уходить из игры и больше не возвращаются в нее. Остановить этот процесс будет уже слишком поздно.
Сплит–тестом вы измеряли данные, которые не точно фиксируют поведение пользователей. DAU и MAU были отстающими индикаторами. Измерять же надо было уровни, достигнутые пользователями.
Миша Ряженка
Founder, Executive Partner
Как измерять Monthly Active Users и другие метрики
Для измерений используют автоматизированные системы аналитики. Они избавляют людей от рутинной работы и формируют понятные отчеты.
Мы собрали список самых удобных инструментов, по мнению аналитиков.
- AppMetrica. Платформа для аналитики и маркетинга приложений. Полностью бесплатная, имеет функции когортного анализа и сегментации аудитории. Автоматически создает отчеты об ошибках в приложении.
- Google Analytics. Бесплатная система для измерения и аналитики главных метрик мобильных приложений. Отслеживает конверсии, показывает статистику в режиме реального времени, формирует перекрестную сегментацию аудиторий, создает отчеты по расписанию.
- Flurry. Платформа на английском языке. Есть бесплатный тариф но функционал в нем ограничен. Работает только с приложениями на Android и iOS. Собирает подробные данные о пользователях, их интересах, действиях и событиях. Может сравнивать одно приложение в двух разных операционных системах, умеет рассчитывать воронку продаж. Заточена под отслеживание поведения пользователей в приложении.
Последнее обновление: 05.04.2023
-
Глава 1. Введение в .NET MAUI
-
Создание кроссплатформенных приложений на .NET
-
Создание проекта .NET MAUI
-
Первое приложение на Android
-
Первое приложение на Windows
-
Первое приложение на iOS
-
Первое приложение для Mac OS
-
-
Глава 2. Создание графического интерфейса
-
Определение приложения на .NET MAUI
-
Страницы и XAML
-
Взаимодействие XAML и C#
-
Создание интерфейса из кода C#
-
Метод LoadFromXaml и загрузка XAML
-
-
Глава 3. Контейнеры компоновки
-
StackLayout, HorizontalStackLayout и VerticalStackLayout
-
AbsoluteLayout
-
Контейнер Grid
-
-
Глава 4. Элементы управления
-
Размеры и позиционирование элементов на странице
-
Работа с цветом
-
Стилизация текста
-
Кнопки
-
Label
-
Текстовые поля Entry и Editor
-
BoxView
-
ScrollView
-
Работа с изображениями. Элемент Image
-
Контейнер Border
-
Выбор даты и времени. DatePicker и TimePicker
-
Stepper и Slider
-
Переключатели Switch и CheckBox
-
RadioButton
-
Выпадающий список Picker
-
TableView
-
WebView
-
Всплывающие окна
-
Индикация прогресса. ProgressBar и ActivityIndicator
-
-
Глава 5. Ресурсы и стили
-
Ресурсы
-
Стили
-
Подключение внешних ресурсов
-
Стилизация с помощью CSS
-
Visual State Manager и визуальные состояния
-
-
Глава 6. Привязка
-
Введение в привязку. BindingContext и объект Binding
-
BindableObject и BindableProperty
-
Режим привязки
-
Форматирование значения привязки и StringFormat
-
Конвертеры значений
-
Свойства и параметры конвертеров
-
Привязка к объектам. Интерфейс INotifyPropertyChanged
-
Относительная привязка
-
-
Глава 7. Триггеры
-
Триггеры свойств
-
Триггеры событий
-
Триггеры данных
-
Мультитриггеры
-
-
Глава 8. ListView и работа с данными
-
ListView
-
DataTemplate и сложные объекты в ListView
-
TextCell
-
Изображения в ListView. ImageCell и ViewCell
-
Создание класса ячейки для ListView
-
ObservableCollection
-
Заголовок и футер в ListView
-
Группировка в ListView
-
Стратегии кэширования элементов ListView
-
-
Глава 9. MVVM
-
Паттерн Model-View-ViewModel
-
Команды и взаимодействие с пользователем в MVVM
-
Параметры команды
-
Отключение команды
-
Организация моделей представления
-
-
Глава 10. CarouselView
-
CarouselView. Создание зацикленного списка
-
Взаимодействие с CarouselView. Обработка выбора элемента
-
-
Глава 11. CollectionView
-
Отображение списка с помощью CollectionView
-
Расположение элементов в CollectionView
-
Выбор элементов в CollectionView
-
Группировка в CollectionView
-
-
Глава 12. Навигация
-
Переходы между страницами и NavigationPage
-
Стек навигации
-
Выбор элементов в CollectionView
-
- Глава 1. Введение в .NET MAUI
- Создание кроссплатформенных приложений на .NET
- Создание проекта .NET MAUI
- Первое приложение на Android
- Первое приложение на Windows
- Первое приложение на iOS
- Первое приложение для Mac OS
- Глава 2. Создание графического интерфейса
- Определение приложения на .NET MAUI
- Страницы и XAML
- Взаимодействие XAML и C#
- Создание интерфейса из кода C#
- Метод LoadFromXaml и загрузка XAML
- Глава 3. Контейнеры компоновки
- StackLayout, HorizontalStackLayout и VerticalStackLayout
- AbsoluteLayout
- Контейнер Grid
- Глава 4. Элементы управления
- Размеры и позиционирование элементов на странице
- Работа с цветом
- Стилизация текста
- Кнопки
- Label
- Текстовые поля Entry и Editor
- BoxView
- ScrollView
- Работа с изображениями. Элемент Image
- Контейнер Border
- Выбор даты и времени. DatePicker и TimePicker
- Stepper и Slider
- Переключатели Switch и CheckBox
- RadioButton
- Выпадающий список Picker
- TableView
- WebView
- Всплывающие окна
- Индикация прогресса. ProgressBar и ActivityIndicator
- Глава 5. Ресурсы и стили
- Ресурсы
- Стили
- Подключение внешних ресурсов
- Стилизация с помощью CSS
- Visual State Manager и визуальные состояния
- Глава 6. Привязка в maui
- Введение в привязку. BindingContext и объект Binding
- BindableObject и BindableProperty
- Режим привязки
- Форматирование значения привязки и StringFormat
- Конвертеры значений
- Свойства и параметры конвертеров
- Привязка к объектам. Интерфейс INotifyPropertyChanged
- Относительная привязка
- Глава 7. Триггеры
- Триггеры свойств
- Триггеры событий
- Триггеры данных
- Мультитриггеры
- Глава 8. ListView и работа с данными
- ListView
- DataTemplate и сложные объекты в ListView
- TextCell
- Изображения в ListView. ImageCell и ViewCell
- Создание класса ячейки для ListView
- ObservableCollection
- Заголовок и футер в ListView
- Группировка в ListView
- Стратегии кэширования элементов ListView
- Глава 9. MVVM
- Паттерн Model-View-ViewModel
- Команды и взаимодействие с пользователем в MVVM
- Параметры команды
- Отключение команды
- Организация моделей представления
- Глава 10. CarouselView
- CarouselView. Создание зацикленного списка
- Взаимодействие с CarouselView. Обработка выбора элемента
- Глава 11. CollectionView
- Отображение списка с помощью CollectionView
- Расположение элементов в CollectionView
- Выбор элементов в CollectionView
- Группировка в CollectionView
- Глава 12. Навигация
- Переходы между страницами и NavigationPage
- Стек навигации
- Выбор элементов в CollectionView
MAU DAU ARPU, или метрики посещаемости, которые надо знать
Приложения для мобильных телефонов приносят деньги тем разработчикам, которые способны быстро подстраиваться под запросы своей аудитории (клиентов). Мало сделать полезное приложение, нужно отслеживать активность его пользователей, вовремя реагировать на спад и рост спроса, проводить адекватную ценовую политику. Этой цели и служат метрики эффективности мобильных приложений, которые мы подробно рассмотрим ниже.
Кстати, новые разработки (это Progressive Web Apps) позволяют совмещать преимущества мобильных приложений и мобильных сайтов. Узнайте о преимуществах PWA, которые позволят вашему сайту получить лидирующие позиции в поисковой выдаче Google. Больше о нововведениях Google для ранжирования мобильных страниц читайте здесь.
Основные метрики мобильных приложений
Установка мобильного приложения производится путем скачивания программы на телефон. Если клиента устраивает работа приложения, то он превращается в активного пользователя. На этом этапе клиента нужно заинтересовать настолько, чтобы ему захотелось иметь расширенную версию приложения, получить дополнительный контент. Довольный и заинтересованный клиент будет готов доплатить за усовершенствованную услугу. Тут-то приложение и начинает приносить деньги своему создателю.
Несложно увидеть прямую взаимосвязь между удовлетворенными пользовательскими ожиданиями и прямой прибылью от приложения. Но как отследить степень «удовлетворенности» клиентов? Это можно сделать, задействуя метрики, которые помогают понять, что нравится пользователям, как они оценивают, к примеру, поднятие цен на дополнительный контент, введение новых платных возможностей и т.п.
Метрики используются в мобильных приложениях, а также играх и стартапах. Разработчик может подключить несколько видов метрик, чтобы получить максимально полную оценку пользовательского спроса. Рекомендуется начинать «снимать» показатели сразу же после первого скачивания приложения клиентом.
Важно вести учет таких метрик:
- Источники установки приложения. Нужны для оценки эффективности используемых вами каналов маркетинга.
- Метрики удержания и вовлеченности пользователей. Показывают, какое количество клиентов запустило ваше приложение после скачивания. К примеру, PCU показывает максимальное количество пользователей, единовременно находящихся в приложении. ACU — это показатель среднего количества пользователей, единовременно находящихся в приложении, за конкретный период.
- Количество уникальных пользователей. Число клиентов, использующих приложение регулярно.
- Сессия – метрика. Показатель продолжительности пребывания пользователя в приложении.
- A/B тесты. Информируют, какие кнопки и в какой последовательности нажимал пользователь.
- Финансовые метрики. Вычисляют эффективность приложения и его прибыльность. Основные финансовые метрики, это ARPPU (доход с одного платящего пользователя) и ARPU (средний доход с пользователя).
Хотите испробовать преимущества новой технологии Progressive Web Apps?
Показатели активности и вовлеченности пользователей
Всем разработчикам мобильных приложений важно понимать, какова активность и вовлеченность их пользователей. Для этого рассчитываются такие метрики, как DAU, WAU, MAU, PCU, ACU.
Что это за активность и о чем она говорит?
Метрики активности дают понять, сколько клиентов уже скачали и используют приложение. Знание этих показателей позволяет оценить пользовательскую аудиторию и проанализировать ее запросы. В итоге, вы получаете «подсказки», к каким маркетинговым ходам нужно прибегнуть. Это первый шаг к увеличению вовлеченности пользователей, и соответственно, ваших доходов.
Обратите внимание на новые правила обработки персональных данных для клиентов из Евросоюза! General Data Protection Regulation: просто о новых правилах обработки персональных данных.
Что такое DAU (Daily Active Users)? Это ежедневные активные пользователи. Метрика демонстрирует, сколько пользователей зашло в приложение за день. Соответственно, WAU (Weekly Active Users) –это еженедельные активные пользователи. А MAU (Monthly Active Users) — это уникальные пользователи, которые посещают приложение хотя бы раз в месяц. Уникальность пользователей определяется по ID или логину.
Пики посещений и степень вовлеченности
Чтобы получить коэффициент вовлеченности пользователя за неделю, нужно разделить «ежедневный» показатель на «еженедельный» (DAU/WAU). Если нужно знать коэффициент «прилипаемости» пользователей к сервису в месяц, сопоставляем «ежедневный» и «ежемесячный» результаты (DAU/MAU).
Хотите понять, когда клиенты наиболее активно используют ваш продукт? Воспользуйтесь метрикой для определения количества пользователей в тот или иной период времени. Отследите показатели среднего и пикового посещения – и делайте выводы.
Итак, PCU (Peak Concurrent User или «пик пользователей онлайн») — это то максимальное количество пользователей, которые одновременно находятся в приложении. Показатель измеряется за час, месяц или год.
В то же время, средний показатель – это ACU (Average Concurrent User или «среднее число пользователей онлайн»). Здесь речь идет о количестве пользователей, которые единовременно находятся в приложении в течение конкретного временного отрезка. Для чего нужны эти показатели? Например, для определения идеального времени для запуска рекламной кампании.
Мы рекомендуем вести статистику и записывать показатели своего проекта, тогда вы будете всегда понимать, нравится ли клиентам ваше приложение, вовлечены и активны ли они, устраивают ли их ваши цены, и когда нужно менять маркетинговую стратегию.
Расчет метрик активности и вовлеченности дает возможность в дальнейшем просчитать финансовые метрики ARPU и ARPPU. Последние показывают прибыль, получаемую как от всех пользователей, так и отдельно от тех клиентов, кто покупает платные версии и контент.
Сегодня в Интернет доступны различные системы аналитики, многими из них можно пользоваться бесплатно. Например, популярными для мобильных приложений сервисами Google Analytics, Flurry и App Annie (однако App Annie взымает плату за некоторые дополнительные метрики).
Если вы используете мобильный сайт или PWA, для возвращения посетителей применяются push-уведомления (показатель конверсии достигает 30%).
Финансовые метрики
С точки зрения прогнозирования прибыли, это самая важная группа метрик.
Основные показатели финансовых метрик
- Gross – брутто-доход за конкретный период;
- Revenue – чистый доход, за вычетом доли магазина, на котором расположено ваше приложение;
- Paying Share – соотношение числа клиентов, которые покупают платные версии, к общему количеству уникальных пользователей. Если показатель снижается, значит, клиенты пресыщены платным контентом, пришло время внести «оживление» (к примеру, провести новую акцию);
- Transactions by User или TBU – количество платежей на одного пользователя. Вычисляется делением общего количества платежей за определенный период на количество плательщиков.
Как рассчитать прибыль
Знание всего двух простых формул позволит сделать выводы, насколько ваше приложение эффективно.
Первая формула подсчитывает среднюю прибыль с одного клиента за конкретный период. Этот показатель ARPU (Average Revenue Per User) определяется путем соотношения брутто-дохода от пользователей к среднему показателю посещаемости в день/неделю/месяц.
Индекс ARPU дает возможность понять, насколько ваш проект эффективен, в целом. Ведь речь идет о доходе от всей аудитории приложения. Индекс зависит, в том числе, от вашей ценовой политики. Однако в большей степени осознать приемлемость ваших цен для ваших клиентов помогает другой показатель, а именно – индекс ARPPU (Average Revenue Per Paying User). Это тоже определитель средней прибыли с одного пользователя за конкретный период, только речь идет уже исключительно о платящих клиентах. То есть, таких, кто приобретает у вас дополнительный контент или услугу.
Для определения индекса ARPPU брутто-доход соотносим с количеством платящих пользователей или PU (число клиентов, оплативших дополнительный контент в конкретный период).
Благодаря показателю ARPPU легко определить прибыльность от платного контента. Тут же можно отметить реакцию пользователей на обновление приложения, на предложение новых услуг или повышение цен.
Разница между ARPU и ARPPU
У многих разработчиков возникают сложности на начальном этапе оценки метрик. В частности, нередко путают индексы ARPU и ARPPU.
Если ARPU, в конечном счете, показывает чистую прибыль с любого пользователя, например, за день, то ARPPU учитывает только ту прибыль, которую вы получили от платящих клиентов. Если в какой-то из дней никто из клиентов не купил дополнительный контент, то показатель ARPPU за этот день будет нулевым.
- ARPU = Revenue / Users (чистый доход «поделить» на количество всех пользователей)
В расчет берутся все пользователи. Этот показатель дает понять, какой доход в среднем приносит один пользователь.
- ARPPU = Revenue / Paying Users (чистый доход «поделить» на количество платящих пользователей)
В расчет берутся только платящие пользователи. ARPPU показывает реакцию пользователей на ваши цены и сколько они готовы платить за платный контент.
- ARPPU > APRU
Так как платящих пользователей намного меньше, чем их общее количество, то показатель ARPPU всегда будет больше APRU.
- ARPU = ARPPU × Paying Share
При поднятии цен у вас может уменьшиться количество платящих пользователей. Paying Share — доля платящих клиентов. В данном случае, показатель прибыли от всех клиентов будет увеличиваться за счет того, что число платящих клиентов упадет после поднятия цен на дополнительный контент. Чтобы привлечь большее число платящих клиентов, нужно выстраивать гибкую и «чуткую» ценовую стратегию.
Примеры расчёта ARPU и ARPPU
Предположим, у вас 2000 пользователей, а 50 из них покупают платный контент. Доход в месяц составляет $5000.
Ваши результаты в месяц:
- ARPU =$5000/2000 = $2,5 (то есть, один «обычный» пользователь платит вам платит $2,5 в месяц);
- ARPPU = $5000/50 = $100 (то есть, один платящий пользователь приносит вам $100 прибыли в месяц);
- Paying Share = 50 / 2000 = 2,5% (таким образом, доля платящих пользователей составляет 2,5%);
- Проверяем: 2,5$ = $100 ×2,5%
Другие полезные финансовые показатели
Помимо прибыли, вы можете подсчитать и свои траты. Например, определить, во что вам обходится привлечение клиентов. Для этого существует индекс CPI (Cost per Install) – это стоимость установки приложения. Благодаря ему можно узнать, сколько денег было потрачено на привлечение новых клиентов. Эта метрика рассчитывается соотношением стоимости рекламы к количеству установок приложения.
Также вы можете определить, насколько эффективен ваш проект за все время его «жизни». Для этого необходимо учитывать индекс LTV (Lifetime Value) — показатель прибыльности за средний период использования приложения одним клиентом.
Для расчета индекса LTV нужно доход от пользователя (ARPU) умножить на показатель средней продолжительности использования или Lifetime.
- LTV=ARPU × Lifetime
Выгоден ли ваш проект? Если LTV меньше CPI, то — не выгоден.
Для улучшения показателя LTV нужно повысить привлекательность приложения, снизить затраты на привлечение новых клиентов, поднять стоимость платного контента.
Рассчитать эффективность маркетинговой рассылки можно при помощи калькулятора эффективности .
Плюсы и минусы использования метрик
| Плюсы использования метрик | Минусы использования метрик |
| Считать такие метрики несложно. Результаты позволят быстро реагировать на любые изменения в запросах вашей аудитории. | DAU — волатильная метрика роста, которая не объясняет причины самого роста. К примеру, будет сложно понять, показатель DAU в конкретный день – это результат удачной PR-кампании, последствие применения маркетинговой стратегии по привлечению новых клиентов или за счет возвращения старых. |
| Многие компании не открывают свои метрики, но с помощью инструментов конкурентной разведки можно оценить объем аудитории конкурента и сравнить показатели роста | DAU/MAU рассматриваются как прокси для оценки внутреннего механизма retention сервиса, но логины пользователей плохо коррелируют с целевыми действиями. |
Аналитика мобильных приложений помогает строить гибкую и результативную модель взаимодействия с клиентами. Ведение статистики и знание целевой аудитории обеспечит успех вашего проекта.
Что такое MAU (Monthly Active Users) в маркетинге
При изучении показателей аналитики проекта часто используется понятие MAU, или Monthly Active Users. Это одна из базовых маркетинговых метрик для оценки посещаемости онлайн-сервиса или мобильного приложения. Анализ показателя MAU помогает определить число активных пользователей в месяц. На основе этого можно оценить вовлеченность и спланировать стратегию продвижения продукта. В данной статье мы расскажем, как измерить MAU, как интерпретировать полученный результат и в каких расчетах участвует данный показатель.
Что такое MAU
Для оценки выбранной стратегии в маркетинге используется множество различных показателей эффективности. В отдельную группу можно выделить показатели вовлеченности пользователей. К ним относятся такие маркетинговые метрики, как DAU, WAU, MAU.
Предлагаем разобраться, что такое MAU, WAU и DAU, как расшифровываются эти названия, что они означают и чем отличаются друг от друга.
- DAU (daily active users) – число активных пользователей за день. Показывает, сколько человек воспользовались приложением или сервисом в течение дня.
- WAU (weekly active users) – число активных пользователей за неделю. Эта метрика учитывает всех уникальных пользователей, которые воспользовались приложением или сервисом в течение недели.
- MAU (monthly active users) – число активных пользователей в месяц. Этот показатель посещаемости в маркетинге учитывает число уникальных пользователей, посетивших приложение или сервис хотя бы 1 раз в течение месяца.
Другими словами, все эти метрики показывают число уникальных посетителей сервиса за определенный период времени. Часто их используют разработчики мобильных приложений. Они помогают проанализировать поведение пользователей и понять, насколько активно юзеры используют приложение. На основе этой информации определяют степень «привязанности» к сервису и планируют стратегию дальнейшего продвижения.
Как измерить MAU
Monthly active users, или MAU – это число уникальных пользователей в месяц, которые хотя бы один раз воспользовались продуктом (речь идет чаще всего о мобильных приложениях): зашли и совершили какие-то действия.
При анализе показателя Monthly Active Users важно учитывать, что не каждого юзера, кто просто открыл приложение, либо зашел на сервис, можно назвать активным пользователем. Поэтому перед началом работы с этой метрикой необходимо определить критерии, по которым активный пользователь отличается от посетителя и попадает в статистику. Как правило, «active user» – это тот, кто получил какую-либо минимальную ценность от посещения сервиса. Что именно станет этой минимальной ценностью – определяется индивидуально и зависит от конкретного продукта.
Итак, важно помнить:
MAU = количество уникальных пользователей приложения за 1 месяц
MAU ≠ количеству запусков приложения в течение 1 месяца
Показатель количества уникальных пользователей в месяц – широко распространенная метрика в маркетинге, которая используется как стартапами, так и крупными международными компаниями.
Сравнение MAU на Facebook за 3 года с учетом разделения пользователей по регионам
Зачем измерять MAU
Любой коммерческий проект, будь это мобильное приложение либо онлайн-сервис, предполагает конечной целью своей работы получение прибыли. Поэтому оценка любых маркетинговых метрик по сути сводится к тому, чтобы понять, как увеличить доходность продукта.
Зачем нужно измерять показатель Monthly Active Users:
- Оценка объема аудитории, которая пользуется продуктом;
- Анализ поведения пользователей в приложении: их активности и вовлеченности;
- Возможность скорректировать работу сервиса при резком ухудшении показателей;
- Составление прогноза, будет ли продукт в дальнейшем приносить прибыль;
- Получение данных для планирования стратегии продвижения продукта.
Метрики активности, в том числе MAU, оценивают в сравнении с количеством скачиваний и установки приложения. Понимание, насколько часто люди пользуются продуктом, помогает проанализировать поведение аудитории. На основе этих данных можно планировать мероприятия по совершенствованию продукта и повышения вовлеченности.
Анализ динамики показателей MAU и DAU
Значение MAU важно в связке с другими метриками активности и вовлеченности. Например, на основе значений количества пользователей в месяц и за неделю, можно рассчитать Sticky Factor. В буквальном переводе это означает «прилипание», или привязанность пользователей к сервису.
Чтобы рассчитать Sticky Factor, нужно найти отношение Daily Active Users к Monthly Active Users:
Sticky Factor = DAU ÷ MAU
Чем выше будет полученное значение, тем регулярнее пользователи заходят на сервис или в приложение в течение месяца. Получается, чем больше Sticky Factor, тем сильнее привязанность пользователей к сервису.
Например, статистика приложения показывает значения DAU 4 тыс и MAU 6,5 тыс. Вычисляем Sticky Factor: 4000 / 6500 * 100 = 61,5%.
Чем выше процент – тем лучше показатель Sticky Factor. В норме он должен постепенно увеличиваться: с развитием проекта приходят новые посетители, и если продукт им нравится – они становятся активными пользователями. Если коэффициент начал падать – это первый сигнал, что что-то пошло не так: продукт перестал решать проблему пользователей либо появился более совершенный аналог.
Цикл взаимоотношений с клиентом с точки зрения маркетинга
Заключение
MAU – одна из маркетинговых метрик, которые используют для оценки числа пользователей продукта и степени их вовлеченности. Она учитывает всех уникальных пользователей в месяц, которые воспользовались продуктом (чаще всего речь идет о мобильных приложениях). Важно помнить, что здесь имеется в виду не просто количество посещений, а количество пользователей, которые тем или иным образом взаимодействовали с продуктом, получив от него определенную пользу. Зная количество уникальных пользователей в месяц и в день (то есть значения MAU и DAU), можно рассчитать Sticky Factor – степень привязанности пользователей к продукту.
Что такое DAU/WAU/MAU. Объясняем простыми словами
DAU/WAU/MAU — метрики пользовательской активности за определённый период: за день (daily active users — DAU), за неделю (weekly active users — WAU) или за месяц (monthly active users — MAU).
Проще говоря, все эти метрики показывают число уникальных посетителей сервиса, которые в течение конкретного временного промежутка хотя бы раз зашли на сайт или в приложение.
Как правило, эти метрики используют разработчики мобильных приложений. Для них это своеобразная мера успешности продукта. На основе DAU/WAU/MAU определяют степень «привязанности» к приложению и планируют стратегию дальнейшего продвижения.
Пример употребления на «Секрете»
«Обычно компании отслеживают базовые данные о работе продукта и поведении пользователя: количество пользователей (MAU/WAU/DAU), длительность сессий, популярные разделы, кнопки, сценарии, источники трафика, средний чек и т. д.».
(Продуктовый аналитик Анна Куликова — о том, как определить необходимые метрики.)
Нюансы
Важно понимать: WAU за определённую неделю — это не сумма DAU за семь дней, поскольку речь идёт об уникальных пользователях. Например, посетитель может зайти в приложение в понедельник и среду, поэтому он попадёт в DAU за эти дни. Но в рамках недельной метрики (WAU) он учтётся только единожды.
Некоторые сочетания основных показателей могут дать косвенные характеристики. Например, если поделить DAU на MAU и преобразовать полученный результат в проценты, можно высчитать месячный коэффициент «прилипаемости» пользователя к сервису (лояльность) — показатель, демонстрирующий, как часто пользователи возвращаются в приложение.
Пример: 10 000 ежедневных активных пользователей / 20 000 ежемесячных активных пользователей = 50% привязываемости. Чем выше этот процент, тем чаще пользователи возвращаются в приложение.